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ABSTRACT 


This  master's  thesis  introduces  the  program  management  and 
concept  of  operations  of  the  TINYSCOPE  Program.  TINYSCOPE 
is  a  6U  CubeSat  designed  as  a  low-cost  and  easily 
replaceable  imaging  spacecraft  that  can  produce  tactically 
relevant  imagery  data.  Tactical  requirements  in  this 
context  would  emphasize  "good  enough"  image  resolution  with 
a  rapid-response  tasking  loop  and  high  revisit  rate.  The 
TINYSCOPE  project  intends  to  demonstrate  the  utility  of 
small,  risk  tolerant  spacecraft  for  tactical  imagery. 

The  program  management  section  of  the  thesis  discusses 
the  relationships  of  cost,  performance,  risk,  and  schedule 
and  the  impact  of  each  on  the  program.  The  program's 
successes  and  failures  are  examined  to  glean  lessons  for 
future  program  managers  of  university  projects.  The 
remainder  of  the  thesis  develops  a  comprehensive  concept  of 
operations  for  the  prototype  spacecraft.  Areas  of 
discussion  include  overviews  of  the  ground,  space  and 
launch  segments  of  the  mission  architecture,  and  proposed 
conduct  of  operations  for  those  segments.  Finally, 
relevant  program  management  and  systems  engineering 
documentation  are  presented  as  appendices. 
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I. 


INTRODUCTION  AND  BACKGROUND 


A.  PURPOSE 

This  master' s  thesis  discusses  the  program  management 
and  concept  of  operations  of  the  TINYSCOPE  Program. 
TINYSCOPE  is  a  6-unit  CubeSat  designed  as  a  low-cost  and 
easily  replaceable  imaging  spacecraft  that  can  produce 
tactically  relevant  imagery  data.  Tactical  requirements  in 
this  context  would  emphasize  "good  enough"  image  resolution 
with  a  rapid-response  tasking  loop  and  high  revisit  rate. 
The  TINYSCOPE  project  intends  to  demonstrate  the  utility  of 
small,  risk  tolerant  spacecraft  for  tactical  imagery. 

The  program  management  section  of  the  thesis  will 
discuss  the  relationships  of  cost,  performance,  risk,  and 
schedule  and  the  impact  of  each  on  the  program  and  on  the 
spacecraft  design.  The  remainder  of  the  thesis  will 
develop  a  comprehensive  concept  of  operations  for  the 
prototype  spacecraft.  Areas  of  discussion  will  include 
overviews  of  the  ground,  space  and  launch  segments,  and 
conduct  of  operations  for  those  segments. 

B.  EVOLUTION  OF  OVERHEAD  TACTICAL  IMAGERY 

1 .  Early  Attempts 

Information  about  a  potential  adversary' s  actions  or 
intentions  provides  a  significant  military  advantage  to  a 
commander.  Thus,  it  has  long  been  sought  after,  often  in 
wildly  inventive  ways.  The  use  of  overhead  imagery  to  gain 
an  aerial  perspective  has  evolved  from  initially  fruitless 
endeavors  into  a  critical  component  of  mission  planning  and 
execution  at  all  levels  of  military  operations. 
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The  earliest  attempts  to  obtain  aerial  images  were 
conducted  by  professional  photographers  using  crude  hot-air 
balloons.  Gaspard  Felix  Tournachon  applied  for  a  patent 
for  aerial  survey  after  developing  a  picture  depicting  a 
birds-eye  view  of  Paris  in  1858  [1]  . 

The  military  utility  of  this  new  technology  was 
quickly  appreciated  and  the  Union  Army  Balloon  Corps  was 
created  under  the  direction  of  Thaddeus  Lowe  [2]  .  At  its 
peak,  the  Balloon  Corps  consisted  of  seven  balloons  capable 
of  rising  to  over  1500  meters  to  allow  "aeronauts"  to  draw 
maps  and  report  on  enemy  activities  through  an  on-board 
telegraph  [3] . 


Figure  1.  Thaddeus  Lowe  observing  the  battle  from  his 

balloon  the  "Intrepid"  Fair  Oaks,  VA  1862.  From  [4] 

Enthusiasm  for  balloon  reconnaissance  waned  by  1863, 


perhaps  due  to  the  inviting  target  that  a  tethered  balloon 
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must  have  presented.  The  necessity  for  reconnaissance  did 
not  fade,  however,  and  new  techniques  were  developed  that 
lessened  the  danger.  Arthur  Batut,  a  Frenchman,  is  known 
as  the  father  of  kite  photography.  His  work.  La 

photographie  aerienne  par  cerf -volant ,  noted  the  potential 
for  kite  photography  as  a  means  to  provide  reconnaissance 
to  militaries.  By  1906,  George  Lawrence,  an  American,  was 
using  strings  of  kites  to  take  panoramic  photos  of  the 
devastation  caused  by  the  San  Francisco  earthquake. 


Figure  2.  Ruins  of  San  Francisco  c.1906.  From  [5] 

Other  attempts  to  satisfy  the  demand  for  imagery 
bordered  on  the  surreal.  In  1908,  Julius  Neubronner  was 
granted  a  patent  for  a  miniature  aerial  camera  designed  to 
be  strapped  to  a  carrier  pigeon.  The  camera  and  subsequent 
photographs  were  a  hit  at  the  Internationale 
Photographische  Ausstellung  in  Dresden  the  following  year 
[6]  . 
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Despite  the  various  methods  attempted  to  legitimize 
the  developing  field  of  aerial  photography,  the  discipline 
did  not  gain  widespread  acceptance  until  the  invention  of 
the  airplane  and  the  World  War  that  soon  followed. 
Reconnaissance  pilots  flew  countless  missions  over  enemy 
trench  lines  to  photograph  the  locations  of  men,  gun 
emplacements,  and  materials.  By  the  end  of  World  War  II, 
aerial  photography  emerged  as  a  critical  capability  for 
strategic  planners. 

2 .  CORONA 

With  the  advent  of  the  Cold  War  came  the  need  to 
determine  the  strategic  capabilities  of  the  Soviet  Union. 
The  CORONA  program  was  designed  to  fulfill  that  need.  The 
program  became  the  first  operational  space  reconnaissance 
platform  on  August  18,  1960.  CORONA  was  a  joint  program  of 

the  Central  Intelligence  Agency  and  the  United  States  Air 
Force.  Over  the  decade  long  life  of  the  program,  CORONA 
gathered  photographic  images  of  more  than  600  million 
square  nautical  miles  of  the  earth.  Images  ranged  in 
resolution  from  25  feet  at  the  beginning  of  the  program  to 
six  feet  as  the  program  drew  to  a  halt.  The  CORONA  program 
is  frequently  showcased  as  an  example  of  how  a  technology 
can  revolutionize  an  industry  [7]. 
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Figure  3 .  First  imagery  recovered  from  CORONA,  Mys  Shmidta 
Air  Field,  USSR.  From  National  Reconnaissance  Office. 


3 .  Current  Technology 

Satellite  technology  has  continued  to  evolve  since 
CORONA.  Current  commercial  satellites  are  capable  of 
producing  images  of  nearly  a  million  square  kilometers  per 
day.  Options  include  multispectral  images  or  panchromatic 
shots  at  resolutions  of  less  than  one-half  meter.  National 
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imagery  collection  systems  are  undoubtedly  capable  of  the 
same  feats.  Unfortunately,  while  technology  has  allowed  us 
to  take  more  and  better  pictures,  physics  still  dictates 
that  a  single  satellite  is  unlikely  to  be  able  to 
photograph  the  same  location  on  earth  more  than  a  few  times 
per  day. 

C .  TINYSCOPE  PROGRAM 

1 .  Background 

Strategic  intelligence  has  traditionally  been  the 
focus  of  imagery  collection,  particularly  space-based 
collection.  However,  as  threats  have  evolved  from  peer 
competitor  states  to  more  regional,  imagery  requirements 
have  adapted  as  well.  Operations  DESERT  SHIELD  and  STORM 
witnessed  a  shift  to  operational  ISR  to  allow  theater 
campaign  planning.  The  trend  continued  toward  lower 
echelon  use  of  national  imagery  systems  throughout  the 
intervening  period  prior  to  the  World  Trade  Center  bombing 
in  2001  [8] . 

Entry  into  Operations  IRAQI  FREEDOM  and  ENDURING 
FREEDOM  further  shifted  the  use  of  overhead  imagery  into 
the  tactical  realm.  The  use  of  Unmanned  Aerial  Vehicles 
(UAVs)  has  become  ubiquitous  even  at  the  platoon  level. 
Along  with  the  UAVs  has  come  a  reliance  on  the  availability 
of  real-time  imagery,  and  thus,  a  demand  for  responsiveness 
that  national  systems  cannot  meet. 

Blocker' s  suggested  solution  is  a  constellation  of 
imaging  nano-satellites  that  would  provide  near  real-time 
imaging  capability  to  the  warfighter  [8]  .  The  TINYSCOPE 
Program  is  an  attempt  to  design,  build,  and  fly  a  prototype 
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nano-satellite  similar  to  the  one  that  Blocker  envisioned. 
The  project  seeks  to  use  the  CubeSat  standard  and 
commercial  off-the-shelf  hardware  as  much  as  possible  to 
develop  a  low  cost  flight  unit  for  flight  testing  and 
concept  validation. 

2 .  CubeSat  Standard 

CubeSat  is  a  pico-satellite  design  standard  that  was 
developed  by  California  Polytechnic  State  University  and 
Stanford  University  in  1999.  The  standard  defines  size  and 
mass  restrictions,  as  well  as  interfaces  with  the 
deployment  system.  A  standard  single  unit  (1U)  CubeSat  is 
a  10cm  cube  and  has  a  mass  of  1.33kg. 


V 


Figure  4 .  1U  CubeSat 

CubeSats  are  commonly  expanded  into  a  3U  form  factor 
measuring  10cm  X  10cm  X  30cm  [9]  .  Both  form  factors  are 
typically  launched  using  a  standardized  CubeSat  deployment 
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system,  such  as  the  Poly  Picosatellite  Orbital  Deployer  (P- 
POD) .  "The  P-POD  is  an  aluminum  box  with  a  door  and  spring 
mechanism  that  can  accommodate  up  to  three  1U  CubeSats  or  a 
single  3U  CubeSat.  Upon  receipt  of  a  deployment  signal  from 
the  launch  vehicle,  a  non-explosive  actuator  (NEA)  releases 
the  door  and  allows  the  CubeSats  to  slide  along  a  series  of 
rails  and  eject  from  the  P-POD  [10]  The  CubeSat  design 
standard  does  not  currently  allow  for  alternative  form 
factors  based  on  the  standard,  however,  a  6U  design  is  in 
development  by  NASA  Ames. 

3.  Program  Objectives 

The  TINYSCOPE  project  intends  to  demonstrate  the 
utility  of  small,  risk  tolerant  spacecraft  for  this 
purpose.  The  objectives  of  the  TINYSCOPE  mission  are 
stated  below. 

a.  The  primary  objective  of  the  TINYSCOPE  program 
is  facilitation  of  student  education  at  the  Naval  Postgraduate 
School . 

b.  The  second  critical  objective  is  to  launch  and 
operate  one  TINYSCOPE  spacecraft  capable  of  obtaining  a  single 
image  of  a  newly  tasked  target  along  a  predetermined  low  earth 
orbit  and  transmit  image  to  a  known  stationary  ground  station. 

c.  Another  objective  is  to  develop  an  attitude 
determination  and  control  system  to  provide  accurate  and  agile 
pointing  for  nano-satellites. 

d.  Finally,  it  is  desired  to  exploit  advantages 
of  CubeSat  platforms.  This  objective  will  require  the  project 
to  include  small  subsystems  requiring  minimal  power,  mass, 
volume,  and  cost  to  operate. 
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II.  TINYSCOPE  PROJECT  MANAGEMENT 


A.  SYSTEM  DEVELOPMENT  PLANNING 

Project  Management  may  be  represented  as  a  discipline 
composed  of  two  constituent  parts:  Systems  Engineering  and 
Project  Planning  and  Control.  Figure  5  depicts  the 

activities,  which  together  comprise  the  project  management 
domain  [11].  In  reality,  the  individual  provinces  may  be 
considerably  less  distinct.  In  our  case,  the  TINYSCOPE 
team  does  not  have  a  dedicated  systems  engineer.  Many  of 
the  tasks  that  would  traditionally  be  performed  by  a 
dedicated  systems  engineer  were  instead  added  to  the 
program  manager's  responsibilities. 


Figure  5.  Systems  engineering  as  a  part  of  project 

management  After  [11] 
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1 .  Feasibility  Assessment 

One  of  the  first  steps  in  the  design  of  any  new  system 
is  the  analysis  of  feasibility.  In  the  case  of  the 
TINYSCOPE  program,  this  assessment  was  performed  by  Blocker 
and  Litton  [12]  .  Blocker  broadly  outlined  the  subsystems 
that  would  be  required  to  develop  a  spacecraft  bus,  while 
Litton  focused  on  the  optical  imaging  payload.  The  two 
efforts  were  complementary;  each  defined  required  functions 
and  interfaces  for  their  respective  components.  Together 
they  developed  an  initial  system  definition,  top  level 
requirements  for  the  system,  and  showed  that  their  proposed 
system  was  feasible  given  current  technologies. 

Blocker  defined  the  TINYSCOPE  system  to  be  a  three- 
axis  stabilized,  low  earth  orbit  satellite  with  an  electro- 
optical  payload.  The  attitude  determination  and  control 
system  (ADCS)  would  be  used  for  stabilization  and  pointing. 
Attitude  and  location  determination  would  be  provided  by 
onboard  sun  sensors  and  star  trackers .  Attitude  control 
would  be  performed  by  either  reaction  wheels  or  control 
moment  gyroscopes.  Imaging  would  be  conducted  on  command 
from  a  ground  station  accessible  by  direct  line  of  sight. 
The  satellite  would  use  a  series  of  slew  maneuvers  to  point 
to  the  targets  and  then  point  back  at  a  ground  station  and 
transmit  the  images  via  a  radio  downlink.  Power 
requirements  for  the  satellite  would  be  met  using  body 
mounted  solar  panels  and  batteries  [8]  .  Litton  described 
the  payload  as  an  axially  mounted  Cassegrain  telescope  with 
an  on  orbit  focusing  mechanism.  Images  would  be  captured 
using  a  COTS  focal  plane  array,  like  those  used  in  digital 
cameras  [  12 ]  . 
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Blocker  and  Litton  used  the  above  system  definition 
and  the  broad  guidelines  outlined  by  the  Operationally 
Responsive  Space  Office  (ORS)  to  develop  a  set  of  top  level 
requirements  for  TINYSCOPE.  These  initial  requirements 
shown  in  Table  1,  served  as  the  foundation  for  the 
TINYSCOPE  program. 


Summary  of  TINYSCOPE  and  Argus  Requirements 


Requirement 

Threshold 

Objective 

Mission 

IOC 

Sep  2011 

ASAP 

note  1 

MMD  -yrs 

1 

2 

note  2 

Storage  Life 

2 

3 

Reliability  confidence 

80% 

80% 

Revisit  ~hrs 

1 

0.5 

note  3 

Images  -per  day 

30 

60 

Task-to-collect  -hrs 

4 

1.75 

note  4 

Task-to-product  ~hrs 

4 

2 

note  4 

Data  Storage  -orbits 

2 

3 

Orbit 

Sun-Synch 

45  to  Sun-Synch 

Imager 

footprint  ~kmA2 

25 

50 

Max  Slew  Angle 

30 

45 

NIIRS 

3 

4 

Spacial  Resolution  ~m 

4 

2.5 

TT&C 

Operations 

MMSOC,  AFSCN 

Imagery  Downlink 

CDL, 

DOGS 

Notes:  1.  Initial  Operational  Capability 

2.  Mean  Mission  Duration 

3.  Revisit  requirement  for  Argus  constellation,  not  individual  satellite. 

4.  Based  on  Mission  Planning  timelines.  Allows  tasking  of  satellite  at 
beginning  of  final  mission  plans  with  product  in  time  for  brief 

Table  1 .  Initial  TINYSCOPE  Top-Level  Requirements 

From  [8] 

2 .  Early  Management  Efforts 

An  important  early  step  in  the  development  of  a  system 
is  a  description  of  the  scope  of  the  project.  A  statement 
of  work  (SOW)  is  typically  used  to  document  broad 
responsibilities,  deliverables,  and  the  work  activities 
required  in  a  given  project.  The  SOW  acts  as  a  guideline 
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for  the  project  and  in  some  cases  is  a  binding  contract 
between  the  vendor  and  the  customer.  The  TINYSCOPE 
program,  like  many  university  projects,  does  not  have  a 
defined  customer.  Instead,  proposals  for  funding  that  were 
submitted  to  sponsoring  agencies  became  the  de  facto  SOW. 
Due  to  the  annual  nature  of  these  funding  proposals,  the 
work  defined  in  each  is  limited  in  scope  to  what  is  to  be 

performed  in  the  funded  year.  The  changes  in  scope  each 

year  inevitably  have  an  impact  on  cost  and  schedule,  but 

seem  to  be  a  byproduct  of  the  lack  of  stable,  long-term 

funding  from  the  sponsors  and  may  also  be  an  inherent  part 
of  the  learning  process  for  any  team  attempting  to  build  a 
satellite  for  the  first  time.  Continuity  was  maintained 
through  focused  meetings  and  a  positive  working 
relationship  between  the  students  on  our  team  and  our 
faculty  advisers. 

Concurrent  with  the  feasibility  analysis  being 
conducted  by  Blocker  and  Litton  in  2007,  TINYSCOPE  was 
being  explored  as  a  student  research  development  project  by 
Dr.  Marcello  Romano.  Initial  proposals  for  funding  were 
limited  in  scope  to  numerical  simulations  and  preliminary 
hardware  testing  for  the  TINYSCOPE  attitude  control  and 
optical  systems.  Deliverables  were  equally  limited;  they 
included  attitude  control  algorithms,  test  data  for  COTS 
optical  components  and  a  prototype  micro-CMG.  Shortly  after 
the  initial  research  proposal,  the  scope  of  the  TINYSCOPE 
program  was  greatly  increased.  By  the  end  of  2008,  there 
were  ideas  to  design,  build  and  launch  a  prototype 
TINYSCOPE  spacecraft.  An  engineering  design  unit  was 
scheduled  to  be  complete  and  functional  by  the  end  of  2009. 

The  proposed  flight  prototype  was  scheduled  to  be  ready  for 
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launch  by  the  end  of  2011.  Efforts  began  immediately  to 
find  suitable  COTS  components  and  where  necessary  to  design 
and  test  custom  hardware  subsystems. 

The  compressed  timeline  and  the  lack  of  a  dedicated 
systems  engineer  forced  much  of  the  documentation  that 
would  be  expected  in  a  project  following  accepted  systems 
engineering  practices  to  be  curtailed.  An  exacerbating 
factor  was  the  lack  of  a  standard  format  for  systems 
documentation.  As  a  result,  the  three  fundamental 

priorities  of  project  management,  cost,  performance,  and 
schedule,  were  often  difficult  to  ascertain  or  finalize, 
but  this,  too,  is  not  unexpected  for  an  inexperienced 
student  team  working  its  way  through  the  complexities  of 
such  a  project.  Capturing  as  much  as  possible  of  what  is 
learned  each  student  cycle  enables  the  next  cycle  to  build 
on  the  experiences  of  the  last. 

Cost  estimation  is  tricky  for  even  an  experienced 
budget  analyst  and  it  should  not  have  been  surprising  that 
initial  estimates  for  the  TINYSCOPE  program  were 
optimistic.  Blocker's  feasibility  assessment  estimated  the 
cost  for  a  TINYSCOPE  satellite  to  be  approximately  $250k 
[8] .  This  number  was  used  as  the  baseline  cost  estimate  for 
the  program.  We  failed  to  appreciate  that  Blocker's 
estimate  was  intended  to  be  a  life-cycle  cost  of  an 
individual  satellite  in  a  constellation  of  360  satellites. 
In  that  case,  development  and  operational  costs  were  to  be 
spread  over  the  entire  constellation.  Our  TINYSCOPE 
prototype  would  require  the  same  development  costs  for  a 
single  satellite,  ballooning  estimates  by  an  order  of 
magnitude . 
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Early  attempts  to  define  requirements  were  vague  and 
incomplete.  The  top-level  requirements  shown  in  Table  1 
along  with  a  minimal  set  of  derived  requirements  gleaned 
from  Blocker's  feasibility  assessment  and  shown  in  Table  2 
served  as  the  program' s  only  requirements  documentation 
well  into  the  preliminary  design  phase.  The  requirements 
that  did  exist  were  poorly  written  and  open  to 
misinterpretation.  As  a  simple  example,  a  top  level 
requirement  in  Table  1  called  for  the  Task-to-product  time 
to  be  within  four  hours  with  an  objective  of  two  hours. 
This  requirement  may  be  interpreted  as  the  time  between 
when  a  Soldier  submits  a  request  for  an  image  to  the  time 
an  image  is  available  to  that  Soldier.  Alternatively ,  it 
may  be  interpreted  as  the  time  between  the  tasking  of  the 
satellite  by  a  ground  station  and  the  time  an  image  is 
transmitted  back  to  the  ground  station.  In  practice,  this 
vagueness  made  it  very  difficult  for  the  student  engineers 
to  design  or  select  subsystems. 
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Top  Level  to  Subsystem  Requirements 

*  EPS  1 1 N ITI A  L  pa  we  r  b  ud^t; 

—  Subjyste T3  will  se  naite  fund  4  Watts  max  {Catr ?rs,  Pay  3a  ad,  EPS,  C&JDH  /  TT4.GJ 
—  M  ED  suiite  Including  njara  by  exoe  ptinn  -[ADCS,  Sum,  Sta’,  M  U,  Mag,  G  PS| 

-  Clyde  Space  PCU 
-  Structure 

—  Capability  ta  bumdh  via  IP -Pad  'jCa-Paly  Require  TentLl 

■  ffiJ :  Utilizing  prirrarilY  COTS  rtrutiulM  Ijcccpti  on  nylond  A  VIED  sj-.ei 

■  :  Utilizing  ajr.au  asits 

—  Pay  a  ad  volume  restricted  ta  10  >:  10  x  SS  cm  at  launch 
—  Initial  mas j  budget  total  10  'kg 

■  2l3  kg  Rnyl'^Jd 

■  1  leg  EPS  tnc  sosr  Brnys 

■  Kg  A  3CS  i  nc  sensa- 

■  3L3  kg  Sbuchre 

■  1  Kg  Ganns 

-  iKgcsu- s- sc 

■  _j  kg  Easing  and  Qnantnn 

*  C  S.  D  H  :  float i  ng  poi  nt  p  racessa  r,_._ 

*  Go  m  ms :  Pay  load  a  nd  co  m  m=  nd  data,  t  r=  nsmit  race  "rue.. _ 

*  ADCS:  .81  deg /sec +/-.  IB . . 

*  Payload  :  G  ive  n  1  ms  exposure,  p  rovide  3  m  GP  D _ 

Figure  6.  Derived  requirements  for  TINYSCOPE  following 
internal  Mission  Requirements  Review 

The  initial  schedule  for  TINYSCOPE,  shown  in  Figure  7, 
was  far  too  aggressive  for  a  student-led  project  of  this 
scope.  Optimistic  assessments  like  this  were  common  when 
the  project  began  due  to  the  inexperience  of  the  team. 
Often  we  failed  to  fully  grasp  the  difficulty  of  our 
undertaking  and  the  environment  in  which  we  worked. 
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Task  Name 

Start 

Finish 

Create  SoacecrattfS/ClDesian  1,  Tinyscope  1 

Mon  10/27/08 

Fri  9/4/09 

Concept  Architecture  /  Development 

Mon  10/27, '98 

Wed  11.26/08 

S/C  DESIGN  1  SYSTEM  FUNCTIONAL  REVIEW  (Internal) 

Frill /1 4/08 

Fri  1 1  /1 4/08 

CRITICAL  DESIGN  DOCUMENTS  (ALCH  Thesis') 

Fri  12/1 9/08 

Fri  12/1 9/08 

HEW1  MISSION  REQUIREMENTS  REVIEW 

Thu  3/1 2/09 

Thu  3/1 2/09 

PRELIMINARY  DESIGN  REVIEW  (Informal  w.SSAG) 

Tue  3/31/09 

Wed  7/8/09 

Develop  S  C  design  (hy  subsystem) 

Mon  10/27/08 

Mon  3/30/09 

Detailed, final  Subsystem  Design 

Mon  1/12/09 

Fri  4/17/09 

TINYSCOPE  S  C  CRITICAL  DESIGN  REVIEW 

Fri  4/1 7/09 

Fri  4/1 7/09 

Tinyscope  Common  Ground  Support  Equipment  (GSE)  Feasibility  Researc 

Mon  1/12/09 

Mon  5/18/09 

Build  Structural  /  MED  Test  Vehicles  (STV)  and  Simulators 

Mon  1/12/09 

Tue  5.26/09 

TINYSCOPE  S  C  IN  PROGRESS  REVIEW 

Fri  5/29/09 

Fri  5/29/09 

Build  S/C  subsystems 

Mon  3.23/09 

Fri  7.24/09 

QualTest  S/C  subsystems  (as  independently  as  possible) 

Mon  3.23/09 

Fri  7.24/09 

TINYSCOPE  S  C  IN  PROGRESS  REVIEW 

Mon  7/6/09 

Mon  7/6/09 

Integrate  Tinyscope  Design  1  (EDU) 

Mon  6/1/09 

Fri  8/14/09 

Qualify, Test  Tinyscope  Design  1  (EDU) 

Mon  8/3/09 

Fri  8.28/09 

SYSTEM  VERIFICATION  REVIEW  /  PRODUCTION  READINESS  REVIEW 

Fri  9/4/09 

Fri  9/4/09 

Oct '08  Nov '08  Dec '08  Jan '09  Feb '09  Mar '09  Apr '09  May '09  Jun'09  Jul'09 


Aug  '09 


Sep  '09 


4  11/14 


4  12/19 

0 


4  312 
^  3:31 


4  417 


4  5/29 


4  9/4 


Figure  7.  Initial  TINYSCOPE  Project  Schedule  10  February 

2  00  9 


With  the  advantage  of  hindsight,  it  is  clear  that  the 
TINYSCOPE  program  had  many  program  difficulties  from  the 
outset.  Most  of  these  shortcomings  can  be  attributed  to  a 
lack  of  experience  and  a  failure  to  understand  the 
importance  of  the  systems  engineering  process  in  the 
development  of  a  system.  Some  of  the  program's 
shortcomings  might  have  been  averted  with  a  rigorous 
documentation  process.  Other  difficulties  were  created  or 
impacted  by  the  university  environment.  Many  of  these 
impacts  will  be  explored  further  in  the  following  section 
including  the  nature  of  our  work  force,  infrastructure,  and 
funding . 

Despite  its  challenges  and  program  difficulties,  the 
TINYSCOPE  project  has  proven  to  be  a  tremendous  learning 
experience.  The  author  has  gained  valuable  experience  as  a 
program  manager  in  an  environment  where  mistakes  were 
tolerated  and  treated  as  an  educational  opportunity.  Many 
of  the  difficulties  that  have  been  examined  in  this  chapter 
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may  have  been  preventable,  but  that  is  often  the  nature  of 
education.  In  any  event,  the  lessons  have  been  learned  and 
will  be  documented  here. 

B.  PROGRAM  MANAGEMENT  CHALLENGES 

1 .  Student  Work  Force 

A  significant  reality  of  any  university  program  is  the 
student  work  force.  There  are  both  advantages  and 
disadvantages  to  the  use  of  student  labor  for  a  satellite 
program,  but  it  requires  planning  and  continued  management 
to  optimize  the  tradeoffs.  The  primary  advantage  to  student 
labor  is  the  knowledge  and  experience  gained  by  the 
student.  Disadvantages  of  student  labor  include 
inexperience,  frequent  turnover,  and  limited  availability. 
However,  with  proper  management  these  disadvantages  can  be 
overcome  or  at  least  minimized. 

The  chief  objective  of  the  TINYSCOPE  program  is  to 
facilitate  the  education  of  the  university' s  student 
population.  Due  to  this,  it  made  practical  sense  that 
student's  would  perform  the  majority  of  the  tasks 
associated  with  the  design,  management,  and  construction  of 
the  satellite.  On  the  TINYSCOPE  team,  individual  students 
were  responsible  for  the  design,  testing,  and  construction 
of  individual  subsystems  of  the  satellite.  Additionally, 
the  team  had  a  student  responsible  for  integration  of  the 
subsystems  and  a  student  program  manager.  Frequent 
interaction  between  our  team  ensured  that  each  participant 
gained  understanding  of  a  good  portion  of  the  breadth  of 
satellite  design. 
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The  members  of  the  TINYSCOPE  team  come  from  varied 
military  and  civilian  backgrounds,  but  the  overwhelming 
majority  had  not  had  prior  experience  in  the  space 
industry.  Instead  the  required  knowledge  and  experience  is 
gained  from  the  curriculum,  through  self-study,  through  on 
the  job  training,  through  hand-overs  with  previous 
students,  and  finally  through  interacting  with  permanent 
support  engineers.  Gaps  sometimes  occur  when  students  join 
the  development  team  before  they  have  gained  the  requisite 
knowledge.  A  key  to  overcoming  these  situations  is  to 
understand  the  institutional  knowledge  and  experience  that 
is  available  from  professors,  staff  engineers,  and  support 
staff  at  the  university  and  collaborating  agencies.  One  of 
the  most  important  lessons  the  author  gleaned  from  this 
experience  was  to  enlist  the  help  and  support  of  those 
persons  early  in  the  planning  process.  It  may  be  helpful 
to  identify  the  types  of  knowledge  or  support  that  will  be 
required  during  the  systems  definition  process  and  then 
list  those  who  may  be  resources  in  planning  documentation. 
Those  persons  should  then  be  encouraged  to  attend  some  or 
all  of  the  team' s  development  meetings  to  provide  their 
perspective  and  insight.  Formalizing  the  relationship 
between  the  design  team  and  external  staff  resources 
through  documentation  will  help  to  capture  any  costs  that 
may  be  associated  with  their  involvement.  It  will  also 
provide  a  starting  point  for  new  members  of  the  team  to 
seek  assistance. 

Another  possible  drawback  to  using  student  labor  is 
their  high  turnover  rate.  Members  of  our  team  average 
approximately  one  year  on  the  team  before  graduating.  Each 

time  a  member  leaves  there  is  a  risk  that  not  only  his 
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experience  will  be  lost,  but  also  that  any  knowledge 
developed  will  disappear  as  well.  Managing  transitions  to 
ensure  that  a  member' s  contributions  are  documented  and 
that  responsibilities  are  assumed  by  another  member  of  the 
team  is  a  significant  challenge.  It  only  took  our  team  a 
single  mishandled  transition  to  realize  the  importance  of 
having  a  standard  procedure  for  outgoing  personnel  to 
follow.  Ideally  this  procedure  would  be  outlined  in  the 
program's  Project  Management  Plan. 

A  final  vital  lesson  that  the  author  learned  in  regard 
to  student  labor  is  to  never  assume  availability.  Students 
join  a  satellite  development  team  to  be  a  part  of  something 
interesting  that  will  have  a  lasting  impact.  At  our 
university  it  is  a  voluntary  act.  Students  will  always 
have  conflicts  between  classes,  other  projects,  and  non¬ 
school  activities  that  will  limit  the  time  available  for 
the  project.  There  will  also  be  periods  of  time  when 
recruitment  of  students  becomes  difficult,  causing  the 
project  to  stall.  At  one  point  in  the  TINYSCOPE 

development,  we  had  five  engineers  one  month  and  one  the 
next.  It  is  important  to  account  for  this  factor  when 
establishing  development  timelines  and  work  and  meeting 
schedules.  Development  timelines  that  are  merely 

aggressive  in  industry  become  unrealistic  in  a  student 
environment.  One  approach  to  resolve  this  dilemma,  proposed 
for  the  first  time  in  this  thesis  since  the  beginning  of 
the  TINYSCOPE  project,  is  to  establish  task  oriented 
metrics  for  measuring  progress  rather  than  a  simple  GANNT 
chart  depicting  start/stop  dates. 
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2. 


Infrastructure 


Special  facilities  are  typically  required  in  order  to 
conduct  integration  and  testing  of  space  systems  [11] . 
These  may  include  facilities  for  environmental  and 
qualification  testing,  environmentally  controlled  areas  for 
testing  and  integration,  or  specialized  test-beds  for 
subsystem  testing.  For  the  TINYSCOPE  program,  our  team 
determined  early  on  that  we  would  require  a  contamination 
controlled  environment  for  subsystem  testing  and 
integration,  as  well  as  final  assembly.  We  also  realized 
that  we  would  require  specialized  equipment  to  test  our 
attitude  control  system  and  optical  payload.  Environmental 
and  qualification  testing  would  be  performed  using 
facilities  available  at  the  university.  To  minimize  our 
production  timeline,  we  decided  to  develop  or  purchase  the 
required  test  and  integration  facilities  in  parallel  with 
design  and  development  of  the  system. 

The  contamination  control  procedures  for  the  TINYSCOPE 
program  are  based  on  the  sensitivities  of  the  on-board 
instrumentation  and  risk  tolerances  for  the  program  as 
defined  in  the  Project  Plan  in  Appendix  A  and  the 
Contamination  Control  Plan  in  Appendix  C.  Generally, 
integration  and  assembly  of  the  spacecraft  subsystems  will 
be  accomplished  in  International  Organization  for 
Standardization  (ISO)  Class  6  clean  rooms.  Our  university 
had  two  such  facilities;  however,  both  facilities  were  in 
use  by  other  projects  during  the  TINYSCOPE  planning  phase. 
Our  team  determined  that  it  was  necessary  to  build  our  own 
facility  in  the  Nano-satellite  Advanced  Concepts  Lab 
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(NACL )  .  Our  facility  was  completed  at  relatively  low  cost 
using  commercially  available  equipment. 

A  new  three-axis  attitude  dynamics,  navigation,  and 
control  hardware  simulator  will  be  used  to  test  the 
hardware  and  the  software  components  of  the  attitude 
control  and  determination  system.  The  simulator  consists  of 
a  pedestal  supporting  a  hemispherical  cup  in  which  the  ADCS 
system  will  be  free  floating  using  a  hemispherical  air 
bearing.  The  air  bearing  will  allow  the  simulation  of  a 
zero  gravity  environment. 

Development  of  an  optical  payload  test  bed  had  not 
begun  at  the  time  this  thesis  was  written.  There  are, 

however,  several  requirements  that  such  a  test  bed  must 

meet.  The  test  bed  must  be  able  to  determine  the  accuracy 
of  the  telescope's  alignment  with  the  focal  array.  This 
can  be  done  in  a  variety  of  ways,  most  commonly  through  the 
use  of  an  interferometer.  The  test  bed  should  allow 
determination  of  the  payload  to  provide  contrast.  Ideally, 
the  test  bed  would  help  to  define  the  modulation  transfer 
function  of  the  telescope  as  well.  The  test  bed  should 

allow  both  the  payload  by  itself  and  the  entire  system  to 
be  mounted  and  tested  in  a  thermal  environment  similar  to 
expected  orbital  values.  Finally,  the  test  bed  should 

allow  measurement  of  distortion  caused  by  vibration  of  the 
spacecraft's  attitude  control  system. 

3 .  Funding 

To  effectively  manage  a  project  it  is  important  to 
correctly  forecast  both  direct  and  indirect  costs 
throughout  the  project  lifecycle.  For  the  TINYSCOPE 


project,  the  primary  investigator  chose  to  maintain  control 
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of  budgetary  decisions  to  preserve  fiscal  partitions 
between  separate  but  complementary  research  areas.  These 
included  the  parallel  development  of  test  facilities  and  a 
separately  funded  nano-satellite  attitude  control  system. 

As  the  student  program  manager,  this  limitation  in 
budgetary  authority  had  benefits.  The  amount  of  time  and 
effort  that  was  required  for  day-to-day  management  tasks, 
such  as  developing  purchase  orders  was  greatly  reduced. 
Additionally,  because  the  program  manager  did  not  have 
visibility  of  travel,  labor,  or  indirect  costs  associated 
with  the  project,  budgetary  estimates  were  easily  developed 
based  on  hardware  costs  only. 

However,  there  were  also  inherent  disadvantages  to 
this  budgeting  scheme.  The  experience  and  knowledge  missed 
by  not  working  through  the  complexities  of  the  university' s 
accounting  and  contracting  process  are  vital  to 
understanding  project  management.  Ownership  of  the  project 
budget  also  forces  the  manager  to  balance  the  relationships 
between  cost,  schedule,  and  performance  to  a  greater 
degree.  In  principle,  monetary  or  labor  assets  may  be 
allocated  to  one  subsystem  that  is  behind  schedule  in  order 
to  bring  the  project  back  into  compliance  with  the 
schedule.  Choices  between  components  that  have  marginally 
different  performance  or  risk  become  much  more  meaningful 
and  are  likely  to  be  more  considered  when  the  decision 
maker  is  responsible  for  the  money  being  spent. 

4 .  Outreach 

One  of  the  unique  and  most  enjoyable  aspects  of  being 

a  student  program  manager  is  the  opportunity  to  engage  with 

other  organizations,  institutions,  and  individuals  pursuing 
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complementary  ideas.  Typical  engagements  may  be  broadly 
categorized  as  marketing,  collaborative,  or  requests  for 
services . 

Marketing  engagements  are  an  opportunity  for  our  team 
to  generate  interest  for  the  project  from  our  eventual 
customers,  the  warfighter.  They  are  also  used  to  gain 
feedback  from  the  personnel  who  will  ultimately  use  the 
imagery  provided  by  the  TINYSCOPE  satellite.  It  is  common 
for  the  student  program  manager  to  provide  marketing 
presentations  to  service  commands  such  as  the  Army' s  Space 
and  Missile  Defense  Command  (SMDC)  and  to  representatives 
of  the  Intelligence  Community. 

Collaborative  engagements  are  conducted  to  share  ideas 
and  foster  relationships  with  other  academic,  civil  or 
commercial  entities  that  work  in  the  small  satellite 
community.  Meetings  may  be  conducted  formally  or  informally 
with  a  single  or  multiple  organizations.  Our  team 

considered  the  annual  CubeSat  Developer's  Workshop  hosted 
by  California  Polytechnic  State  University  to  be  an 
excellent  forum  for  the  exchange  of  ideas  and  perspectives. 

Requests  for  services  may  be  for  funding,  technical 
assistance  or  launch  and  integration  services.  The 

TINYSCOPE  program  relies  on  funding  from  external 
government  agencies  to  operate.  The  funding  cycle  is 
annual  and  does  not  usually  allow  fiscal  assets  to  be 
carried  over  from  year  to  year.  This  necessitates  annual 
proposals  to  request  additional  research  funding  for  the 
project.  It  also  requires  that  periodic  progress  briefs 
are  presented  to  sponsoring  agencies.  Launch  services  for 
scientific  or  experimental  Department  of  Defense  (DoD) 
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satellites  are  provided  through  the  Space  Test  Program 
(STP)  .  The  STP  manifests  experiments  which  either  enhance 
or  provide  new  capabilities  to  the  DoD  and  that  have  been 
approved  by  the  Space  Experiments  Review  Board  (SERB) .  The 
TINYSCOPE  project  has  received  annual  approval  as  an 
eligible  experiment  since  2008. 

C.  SYSTEMS  ENGINEERING  EVOLUTION 

There  is  a  complex  interrelationship  between  cost, 
performance,  schedule,  and  risk  that  must  be  balanced 
effectively  in  a  systems  development  program.  Cost  and 
schedule  are  directly  linked;  similarly,  cost  has  direct 
linkage  to  performance  and  risk.  As  an  example  of  these 
relationships  assume  that  schedule  and  risk  remain  constant 
while  performance  requirements  increase;  the  cost  of  the 
program  will  likely  increase.  Performance,  schedule  and 
risk  are  all  indirectly  linked  to  each  other  through  cost. 
The  function  of  managing  the  relationships  between  these 
elements  is  the  responsibility  of  the  project  manager.  The 
key  to  success  is  appropriate  planning  and  documentation. 
As  I  have  already  described,  the  TINYSCOPE  program  suffered 
from  a  lack  of  planning  and  documentation  from  its 
inception.  This  was  apparent  almost  immediately  after 
volunteering  to  be  the  program  manager.  Our  team  attempted 
several  stopgap  measures  to  keep  the  program  on  track  but 
our  inexperience  was  palpable.  Figure  8  is  an  early 
attempt  to  manage  our  requirements  gap.  We  developed  key 
performance  parameters  with  objective  and  threshold  values 
to  define  the  capabilities  we  expected  of  our  system. 


KPP 

Description 

Objective 

Threshold 

Units 

001 

Mission  life  (Design  Life) 

2 

5 

yrs 

002 

Reliability 

80 

50 

% 

003 

Earth  imaging  resolution  (sensor) 

1* 

5 

m 

003.a 

Assuming  orbit  altitude 

450-550 

400-600** 

km 

003.  b 

Orbit  inclination 

60-98 

sun  synch 

deg 

003.C 

Effective  field  of  view 

50 

25 

km2 

004 

Satellite  Mass 

10 

20 

kg 

004.  a 

Deploy  from  available  design 

P-POD 

NASA 

m3 

006 

Downlink  tactically  usable  imagery 

4 

1 

images 

006.  a 

Telemetry  and  Command  up-link  /  down-link 

ITGT  and  or  other  SAT 

NPS** 

006.  b 

Payload  Data  down-link 

ITGT  and  or  other  SAT 

NPS** 

006.  c 

Ground  station  antenna  size 

3 

10 

m 

007 

Tactical  Slew  Maneuver:  Serviced  Users /Target  assignment 

007.  a 

Number  of  targets  during  pass 

^*** 

2** 

targets 

007.  b 

Angle  between  target 

60 

30 

deg  (angle) 

0007.  c 

Latitude  bounds 

10 

5 

deg  (latitude) 

008 

Cost 

500 K 

1M 

$ 

009 

Geo  Location 

100 

200 

m 

010 

Storage  Capability 

36 

12 

images 

Note  *  -  estimated  capability  orbit  dependent:  desired  mission  altitude  vs  mission  life 
Note  **  -  assumed  precedence  during  prototype  increment 
Note  ***  -includes  ground  station  acquisition  and  4target  areas 


Figure  8.  TINYSCOPE  Key  Performance  Parameters  July  2009. 

Development  delays  and  frequent  miscommunication  among 
team  members  about  responsibilities  and  interfaces  remained 
prevalent.  As  development  continued,  the  author  again 
realized  that  these  measures  were  not  enough,  so  in  2010, 
we  began  a  systematic  overhaul  of  the  program  beginning 
with  a  project  plan,  a  reconstructed  requirements  document 
and  a  task  oriented  schedule. 

The  TINYSCOPE  project  plan  in  Appendix  A  describes  the 
work  activities  required  to  develop  a  flight  prototype.  It 
acts  as  the  defining  document  for  the  program' s  mission  and 
objectives  and  describes  the  technical  approach  that  will 
be  used  by  the  development  team.  It  additionally  defines 
criteria  for  minimum  and  complete  success  of  the  system 
upon  launch.  The  document  outlines  the  team's  management 
and  product  structure  and  provides  a  baseline  schedule  and 
budget  estimation  for  the  program.  The  project  plan  acts 
as  a  foundation  document  for  all  other  TINYSCOPE 
documentation . 
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The 

Certification 

and 

Requirements 

Document  in 

Appendix 

B  describes  all 

of 

the  system' s 

bus , 

payload. 

mission 

and  technology. 

and 

master  satellite 

interface 

requirements.  It  additionally  defines  required  tests  and 
inspections  for  the  system  and  describes  the  methods  and 
analysis  procedures  for  the  test  and  certification  program. 
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Ill .  TINYSCOPE  CONCEPT  OF  OPERATIONS 


A.  MISSION  ARCHITECTURE 

1 .  Space  Environment 

TINYSCOPE  will  conduct  normal  operations  in  a  low 
earth  orbit.  The  nominal  orbit  is  sun-synchronous  and 
circular  at  an  altitude  of  400  kilometers.  The  natural 
environment  at  this  orbit  includes  the  gravitational 
fields,  plasma,  magnetic  fields,  energetic  charged 
particles,  galactic  cosmic  rays,  and  meteoroids.  An 
additional  concern  is  manmade  orbital  debris. 

a.  Perturbations 

The  Earth-Moon  system  will  perturb  the  TINYSCOPE 
spacecraft' s  orbit  due  to  eccentricity  of  the  Earth-Moon 
orbit  and  the  rotation  of  the  Earth  and  Moon.  The  planets 
will  also  perturb  the  orbits  with  Jupiter  and  Venus  acting 
as  the  primary  sources.  Additional  sources  of  perturbation 
include  solar  radiation  pressure  and  atmospheric  drag. 
These  perturbations  will  vary  due  to  attitude  changes  of 
the  spacecraft. 

Jb.  Plasma 

A  spacecraft  in  a  Low  Earth  orbit  is  subject  to 
plasma  environments  due  to  both  the  solar  wind  and  the 
geomagnetic  tail.  TINYSCOPE  will  operate  within  this 
extremely  dynamic  plasma  environment  risking  damage  from 
spacecraft  charging,  contamination,  and  interference  with 
communication  and  other  electronic  hardware  due  to 
scintillation  and  wave  refraction.  Typical  charged 
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particles  will  have  energies  of  a  few  hundred  kilovolts. 
Differential  collection  of  charge  on  the  external  surfaces 
of  the  spacecraft  may  lead  to  electrostatic  discharge 
events  and  attraction  of  contaminants .  Severe  charging  can 
also  interfere  with  electronic  systems. 


space 

hazard 

spacecraft 

charging.; 

single  event  effects 

total  radiation  dose 

surface 

degradation 

piasma 

interference  with 
spacecraft 
communication 

specific 
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cosmic 

rays 
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tion 
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sputter¬ 
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wave 
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Table  2.  Space  Environment  Hazards  by  Orbit  From  [13] 


c.  Energetic  Particles 

TINYSCOPE  will  be  subject  to  the  effects  of 

energetic  particles,  or  ionizing  radiation,  produced  by 

solar  flares  and  coronal  mass  ejections,  the  geomagnetic 

tail,  and  galactic  cosmic  rays.  The  spacecraft  will  also 

encounter  ionizing  radiation  trapped  in  the  Van  Allen  belts 

and  in  particular  the  South  Atlantic  Anomaly.  This 

ionizing  radiation  can  cause  several  types  of  damage. 

These  effects  include  measurable  changes  in  properties  of 

28 


semiconductors  and  a  deterioration  of  the  thermal  radiation 
properties  of  materials  due  to  the  cumulative  penetration 
of  the  particles.  The  energetic  particles  can  also  cause 
single  event  upsets  to  microcontrollers  and  changes  in  the 
surface  reflectivity  and  transmission  properties  of  optical 
sensors.  Energetic  particles  will  also  add  noise  to  images 
due  to  direct  impacts  with  the  sensor.  This  effect  will  be 
measurably  more  pronounced  during  periods  of  high  solar 
activity . 

d.  Surface  Degradation  Hazards 


Low 

Earth  orbital  atomic 

oxygen 

is 

highly 

reactive 

and 

erodes  the  external 

surfaces 

of 

surface 

materials . 

Atomic  oxygen  is  very 

damaging 

to 

surface 

optical  properties  while  some  coatings,  such  as  silver  and 
osmium,  are  seriously  degraded  resulting  in  material 
removal  or  surface  roughness.  UV  degradation  may  occur  as 
well  due  to  the  presence  of  ultraviolet  and  X-ray 
wavelengths.  It  is  expected  that  some  amount  of  sputtering 
will  occur  but  it  is  unlikely  to  limit  operation  of  the 
spacecraft . 

e.  Orbital  Debris  and  Meteoroids 

Orbital  debris  will  be  a  major  concern  for  the 
spacecraft.  There  are  currently  over  20,000  catalogued 
objects  greater  than  five  centimeters  in  diameter  in  the 
low  earth  orbit  environment.  Kinetic  impacts  with  debris 
objects  could  potentially  be  fatal  to  the  spacecraft. 
Expected  mass  of  meteoroids  will  be  between  .001  and  1 
gram. 
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2 .  Space  Segment  Overview 
a.  Payload 

The  TINYSCOPE  payload  consists  of  an  optical 
telescope  and  a  focal  plane  array.  The  telescope  is  a 
Matsukov-Cassegrain  design  with  a  spherical  primary  mirror 
and  a  slightly  aspherical  secondary  mirror  mounted  near  the 
focus  of  the  primary  mirror,  as  depicted  in  Figure  9.  The 
secondary  mirror  includes  a  smaller  meniscus  corrector  in 
the  center  that  reduces  off-axis  aberration  and  narrows  the 
field  of  view.  The  effective  focal  length  of  the  telescope 
is  1.45  meters.  The  diameters  of  the  primary  and  secondary 


mirrors 

are 

each  9.3  centimeters. 

The 

mirrors 

will 

be 

aligned 

and 

focused  on  the  ground 

and 

do  not 

have 

an 

onboard  focusing  mechanism. 


Figure  9.  Light  path  of  a  Matsukov-Cassegrain  telescope. 

The  focal  plane  array  consists  of  a  4.8 
centimeter  monochrome  Complementary  Metal  Oxide 
Semiconductor  (CMOS)  housed  in  a  Toshiba_Teli ,  machine 
vision  camera  housing.  The  planar  array  is  4096  pixels  by 
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3072  pixels  and  each  pixel  is  6.0  micrometers  square.  Each 
pixel  has  a  dynamic  range  of  up  to  ten  bits.  The  camera 
has  an  electronic  shutter  and  is  capable  of  capturing  25 
frames  per  second  at  full  resolution. 


b.  Spacecraft  Bus 


The  TINYSCOPE  bus  provides  power  to  the  focal 
plane  array,  attitude  control,  command  and  data  handling 
and  communications.  The  bus  is  constrained  to  be  a  6U 
CubeSat  form  factor  and  subsystems  are  limited  to  one  half 
of  the  overall  volume  as  shown  in  Figure  10. 


ATTITUDE  - 

DETERMINATION 


ATTmiDF 

CONTROL 


EPS 


C&DH  / 
COMMUNICATIONS 


PAYLOAD 


Figure  10.  TINYSCOPE  Volume  Configuration 


(1)  Electrical  Power  Subsystem  (EPS) .  The 
EPS  consists  of  the  power  controller,  the  solar  arrays  and 
the  batteries.  The  power  controller  provides  regulated 
power  to  the  payload  and  bus  subsystems.  It  conditions  the 
power  generated  by  the  solar  arrays,  provides  circuit 
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protection,  and  monitors  the  battery  state  of  charge.  The 
solar  arrays  will  use  GaAs  solar  cells  to  power  the 
spacecraft.  The  battery  will  provide  initial  power  to  the 
spacecraft  following  launch  and  will  provide  power  during 
normal  operations  when  the  spacecraft  is  not  sun  soaking. 

(2)  Attitude  Determination  and  Control 
Subsystem  (ADCS) .  The  ADCS  will  provide  location  and 
attitude  knowledge,  momentum  management  and  pointing 
control  to  support  normal  operations.  Attitude  and 
location  determination  will  be  provided  by  a  combination  of 
sun  sensors,  a  star  tracker,  an  inertial  measurement  unit 
and  an  on-board  Global  Positioning  System  (GPS)  receiver. 
Pointing  control  will  be  performed  by  reaction  wheels.  The 
ADCS  will  control  spacecraft  slew  maneuvers  in  response  to 
commands  from  the  ground  station  and  to  return  the 
spacecraft  to  a  sun  soaking  attitude.  Magneto-torquer 
coils  will  be  used  to  dump  momentum  when  the  reaction 
wheels  become  saturated  or  in  response  to  commands  from  the 
ground  station. 

(3)  Thermal  Control  Subsystem  (TCS) .  The 
TCS  will  be  a  passive  radiation  system.  The  spacecraft 
structure  will  act  as  a  heat  sink  to  collect  thermal  energy 
from  subsystems.  Heat  will  be  radiated  through  flat-plate 
body  mounted  radiators. 

Command  and  Data  Handling  Subsystem  (C&DH) . 
The  C&DH  subsystem  consists  of  the  command  and  data 
processor,  solid  state  data  storage,  and  the  cabling  that 
provides  connectivity  to  the  other  spacecraft  subsystems . 
The  command  and  data  processor  controls  the  spacecraft 
subsystems  and  manages  the  spacecraft  state  of  health.  The 
processor  will  compress  collected  images  and  segment  the 


32 


data  for  transmission  to  the  ground  station.  The  data 
storage  is  used  to  store  collected  images  and  state  of 
health  logs  between  contacts  with  the  ground  station. 

Communications  Subsystem.  The  communications 
subsystem  provides  two  way  communications  for  command 
uplink  and  telemetry  and  data  downlink.  The  S-Band  radio 
will  operate  at  2.4  GHz  and  will  provide  a  data  rate  of  1.2 
Mbps  through  a  directional  antenna.  A  secondary  omni¬ 
directional  antenna  will  provide  low  rate  communications 
for  telemetry  and  commands  during  contingency  operations. 

3 .  Ground  Segment  Overview 

The  TINYSCOPE  ground  segment  includes  the  Mission 
Operations  Center,  the  ground  station  and  associated 
networks.  The  Mission  Operations  Center  (MOC)  is 
responsible  for  flight  operations,  activity  planning  and 
data  management.  The  ground  station  acts  as  the 
communications  element  of  the  ground  segment.  The  ground 
station  is  required  to  provide  daily  contact  with  the 
spacecraft  to  allow  telemetry  and  data  downlink  and  command 
uplink.  Ground  segment  networks  include  the  link  between 
the  ground  station  and  the  Mission  Operations  Center,  the 
Naval  Postgraduate  School  Intranet,  and  the  internet. 

a.  Mission  Operations  Center 

The  Mission  Operations  Center  consists  of  three 
operational  elements:  flight  operations,  activity  planning 
and  data  management.  The  flight  operations  element 
communicates  with  and  controls  the  satellite  through  the 
ground  station.  Activity  planning  and  data  management 
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interact  with  the  end  user  of  the  TINYSCOPE  product. 
Figure  11  shows  how  each  element  interacts  with  others. 


Figure  11.  Mission  Operations  Center  elements 


b.  Ground  Station 

The  TINYSCOPE  ground  station  will  provide  an 
intermittent  link  between  the  satellite  and  the  flight 
operations  element.  Currently,  we  plan  to  utilize  the 
ground  station  on  the  Naval  Postgraduate  School  campus  that 
was  built  for  another  NPS  satellite  project,  the  NPSAT1 
[14].  The  ground  station  consists  of  a  steerable  antenna, 
a  telemetry  tracking  receiver,  high  and  low  frequency 
synthesizers  and  computer  hardware  with  orbit  propagation 
software.  A  diagram  of  the  architecture  is  in  Figure  12. 
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Figure  12 .  Ground  Station  Communications  Architecture  From 

[14] 


The  steerable  antenna  is  a  3.048  meter  in 
diameter  mesh  parabolic  dish.  The  antenna's  beamwidth  is 
between  three  and  four  degrees.  The  pointing  accuracy  is 
approximately  two  and  one  half  degrees.  The  antenna  has  a 
maximum  elevation  of  90  degrees  and  azimuth  limitations  of 
374  degrees,  which  will  create  a  keyhole  effect  as  a 
satellite  passes  overhead,  reducing  contact  times  with 
flight  operations  [14] . 

The  antenna  steering  is  controlled  by  the 
telemetry  tracking  receiver,  which  locks  onto  the  signal 
from  the  satellite.  The  receiver  sends  commands  to  a 
controller  box,  which  then  engages  azimuth  and  elevation 
motors  to  move  the  antenna.  The  orbit  propagation  software 
predicts  the  satellite's  orbital  position  based  on  previous 
ephemeris  to  provide  the  antenna  controller  with  an  initial 
search  position. 
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c.  Ground  Segment  Networks 

The  ground  segment  networks  provide  physical 
links  between  the  mission  operations  center  and  the  ground 
station  and  allow  end  users  to  gain  access  to  archived 
images.  The  campus  intranet  will  be  used  for  the  former 

purpose  using  existing  cabling.  Archived  images  will  be 
placed  in  a  database  by  the  data  management  element  and 
will  be  available  via  a  web  interface. 

B .  OPERATIONS  DESCRIPTION 

1 .  Spacecraft  Operations 

The  TINYSCOPE  satellite  points  to,  and  takes 

panchromatic  images  of,  specified  locations  on  the  earth 
and  transmits  the  images  to  a  ground  station.  Generally, 
the  satellite  will  receive  a  command  from  a  ground  station 
to  image  one  or  more  locations.  The  satellite  will  then 

calculate  the  necessary  slew  maneuvers  to  point  to  the 
specific  locations,  conduct  a  maneuver  and  record  an  image, 
and  then  continue  to  the  next  location.  Upon  completion  of 
assigned  missions,  the  satellite  will  slew  back  to  point  at 
the  ground  station  and  transmit  the  image  data.  Ground 
controllers  also  have  the  option  to  command  that  images  be 
taken  and  stored  for  transmittal  upon  the  next  access  to 

the  ground  station.  Finally,  the  satellite  seeks  a  sun- 
soaking  orientation  when  not  performing  a  tasked  mission. 
Each  of  the  subsystems  plays  a  role  in  ensuring  that  the 
satellite  can  perform  its  primary  function. 

a.  Operational  Modes 

The  TINYSCOPE  spacecraft  has  three  operational 

modes . 
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NORMAL  Mode  is  the  standard  operational  mode  for 
the  spacecraft.  In  this  mode  the  spacecraft  can  perform 
image  collection  and  all  of  the  supporting  tasks  that  are 
required. 

SAFE  Mode  provides  a  safe  haven  for  the 
spacecraft  when  required  by  environmental  conditions  or 
anomalies.  This  mode  is  designed  to  allow  the  spacecraft 
to  maintain  limited  functionality  but  still  protect 
components  from  damage.  In  this  mode,  the  spacecraft  can 
no  longer  perform  image  collection.  The  payload  and  S-band 
radio  are  deactivated  and  the  spacecraft  seeks  an 
orientation  to  allow  the  solar  arrays  full  access  to  the 
sun.  The  beacon  radio  transmits  continuous  telemetry  data 
through  the  omni-directional  antenna.  Recovery  from  SAFE 
mode  requires  intervention  from  the  ground. 

EMERGENCY  Mode  is  used  when  the  spacecraft  is  in 
immediate  danger  of  a  critical  failure  or  mission  ending 
damage.  All  subsystems  with  the  exception  of  the  beacon 
radio  are  deactivated.  The  beacon  transmits  a  periodic 
distress  signal  along  with  telemetry  data  to  preserve 
power.  The  EPS  deactivates,  as  well  as  provides  a  direct 
path  from  the  solar  array  to  the  battery  for  charging.  The 
spacecraft  is  not  capable  of  image  collection,  high  rate 
communication,  or  attitude  control  in  EMERGENCY  Mode. 
Recovery  from  this  mode  requires  that  the  ground  station 
intervene  by  sending  a  hardware  command  to  the  beacon  radio 
to  reactivate  the  processor  and  load  a  software  update. 
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b .  Telemetry ,  Tracking,  and  Command  (TT&C) 
Operations 

TINYSCOPE  has  two  antennas,  one  directional  and 
one  omni-directional  to  transmit  and  receive  TT&C  data. 
The  S-Band  transceiver  periodically  transmits  telemetry 
data  through  the  omni-directional  antenna  regardless  of  the 
satellite's  position  relative  to  the  ground  station. 
Telemetry  data  includes  position,  orientation  and  state  of 
health  information.  During  normal  operations,  the 
satellite  will  perform  a  slew  maneuver  to  orient  the  high 
gain  antenna  towards  the  ground  station  thirty  minutes 
prior  to  contact  and  remain  in  this  attitude.  It  will  then 
transmit  a  pulsed  tone  to  allow  the  ground  station  antenna 
to  track.  Upon  initial  contact  with  the  ground  station, 
the  TINYSCOPE  satellite  will  send  recorded  telemetry  data 
to  the  ground  station  and  then  standby  for  command  uplink. 
Command  uplinks  will  include  clock  synchronization, 
authentication  and  a  command  script.  The  TINYSCOPE 
satellite  will  authenticate  all  command  uplinks  before 
execution . 


c.  Data  Operations 

The  TINYSCOPE  spacecraft  has  the  capability  to 
store  three  types  of  data.  Command  sequence  data  tells  the 
spacecraft  which  missions  and  maintenance  activities  to 
conduct.  Telemetry  data  are  gathered  from  each  subsystem. 
It  is  essentially  a  log  of  functions  performed,  system 
status  and  environmental  conditions.  Mission  data  are  the 
images  that  the  satellite  collects.  Each  type  of  data  is 
stored  in  separate  partitions  on  the  solid  state  recorder. 
When  the  spacecraft  is  commanded  to  downlink  stored  data. 
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telemetry  data  are  transmitted  first  followed  by  already 
executed  and  unexecuted  command  sequence  data  and  then 
mission  data.  Individual  images  are  treated  as  separate 
files  by  the  spacecraft.  Upon  receiving  acknowledgement 
that  data  has  been  received,  the  spacecraft  will  free  the 
data  to  be  overwritten  on  the  solid  state  recorder.  If  a 
file  is  not  acknowledged  by  the  end  of  the  contact,  the 
spacecraft  will  retransmit  the  entire  file  at  the  next 
contact . 


d.  Pointing  Operations 

The  TINYSCOPE  spacecraft  is  attitude  stabilized 
in  three  axes  by  the  ADCS  subsystem.  Position  and  attitude 
determination  is  performed  continuously  by  the  spacecraft. 
Pointing  control  of  TINYSCOPE  is  provided  autonomously  by 
the  spacecraft  processor.  The  processor  gathers  data  from 
attitude  and  position  sensors  and  pointing  commands  from 
the  ground,  determines  the  required  momentum  adjustment  and 
issues  commands  to  actuators. 

Slews  are  vehicle  maneuvers  that  orient  the 
spacecraft  to  collect  mission  data,  to  communicate  with  the 
ground  via  the  high  gain  antenna,  and  to  orient  the 
spacecraft  for  power  management  operations.  The  spacecraft 
uses  momentum  management  to  perform  slew  maneuvers.  Slews 
may  be  initiated  autonomously  by  the  spacecraft  or  by 
command  from  the  ground.  A  typical  slew  maneuver  begins 
with  a  real-time  or  sequenced  command  to  collect  an  image 
of  a  ground  target.  The  spacecraft  will  perform  constraint 
checks  for  sun  avoidance  and  then  point  to  the  calculated 
position  on  the  earth's  surface  and  then  settle.  Settling 
time  allows  the  attitude  determination  subsystem  to 
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reacquire  position  and  attitude  knowledge.  The  spacecraft 
then  uses  fine  momentum  adjustments  to  maintain  the  target 
in  the  center  of  the  image  field  and  to  null  the  effects  of 
motion.  Errors  may  be  generated,  if  pointing  to  the  target 
would  violate  a  constraint,  or  if  the  calculated  slew 
profile  will  cause  the  momentum  stored  by  the  reaction 
wheels  to  exceed  predefined  limits.  In  these  cases,  the 
spacecraft  will  unload  momentum  by  magneto-torquers  prior 
to  the  maneuver  or  not  execute  the  command. 

e.  Power  Management  Operations 

Power  management  functions  for  the  TINYSCOPE 
spacecraft  will  be  handled  autonomously  by  the  EPS 
subsystem.  The  power  controller  will  regulate  power  to 
spacecraft  subsystems.  It  will  manage  loads  based  on  the 
spacecraft's  operating  mode  and  power  profiles.  The 
controller  will  also  provide  automatic  charge  of  the 
batteries.  When  the  spacecraft  is  not  actively  pointing 
for  imagery  collection  or  communications,  the  spacecraft 
will  orient  the  solar  array  panels  towards  the  sun  to  allow 
the  batteries  to  charge. 

2 .  Ground  Systems  Operations 

The  end  user  for  the  TINYSCOPE  satellite  will  be  the 
student  and  faculty  population  at  the  Naval  Postgraduate 
School.  Imagery  may  be  used  for  research  in  the  field  of 
remote  sensing.  Archived  imagery  may  also  be  available  to 
the  general  public  through  the  internet.  Generally, 
imagery  will  be  requested  through  a  proposal  to  the 
activity  planning  element,  the  flight  operations  element 
will  generate  the  commands  required  to  execute  the  proposal 
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and  the  data  management  element  will  archive,  process  and 
distribute  the  images.  This  sequence  may  be  categorized 
into  Pre-mission  Operations,  Mission  Execution,  and  Post- 
Mission  Operations. 

a.  Premission  Operations 

Premission  Operations  includes  activities 
necessary  to  solicit,  review  and  approve  proposals  for 
imagery,  schedule  mission  and  maintenance  activities,  and 
conduct  long  range  planning. 

TINYSCOPE  is  expected  to  have  excess  capacity  for 
image  requests  after  commissioning  and  pre-planned  proof  of 
concept  tests  have  been  completed.  In  this  instance, 
additional  requests  for  imagery  will  be  solicited.  Research 
proposals  from  NPS  students  and  faculty  will  likely  be 
accommodated  first,  but  there  may  be  an  opportunity  to  use 
some  of  the  excess  capacity  for  Science,  Technology, 
Engineering,  and  Mathematics  (STEM)  outreach  programs  with 
local  schools. 

Regardless  of  the  source,  proposals  for 
collection  will  contain  basic  information  on  the  research 
objective,  requested  location,  constraints  on  viewing 
geometry  and  weather,  and  how  the  image  will  be 
distributed.  The  activity  planning  element  of  the  MOC 
will  conduct  monthly  boards  to  review  proposals.  The  board 
will  ensure  that  the  requested  image  is  not  militarily 
sensitive  and  that  it  does  not  violate  the  Land  Remote 
Sensing  Policy  Act  of  1992.  Proposals  will  then  be 
prioritized  based  on  requested  time  constraints  and  the 
board's  view  of  the  proposal's  merit.  Finally,  the 
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prioritized  list  of  proposals  to  be  scheduled  will  be 
approved  by  the  supervising  faculty  member  and  archived  by 
the  data  management  element. 

The  activity  planning  element  is  also  responsible 
for  scheduling  via  the  spacecraft  mission  plan  and  a 
detailed  activity  plan.  Approved  proposals  and  spacecraft 
maintenance  activities  will  be  scheduled  in  the  mission 
plan  based  on  priority  and  availability  of  appropriate 
viewing  geometry.  The  mission  plan  identifies  primary 
activities  for  the  activity  plan,  special  considerations  or 
constraints,  and  viewing  geometry. 

The  mission  plan  is  translated  into  an  activity 
plan  depicting  resource  allocation,  event  durations  and 
times.  The  activity  plan  is  a  detailed  minute  by  minute 
ordering  of  an  event  sequence.  An  activity  plan,  like  the 
one  shown  in  Figure  13,  will  go  directly  to  the  flight 
operations  element  for  command  sequencing. 


a.  STK  Scheduler  -  [TINYSCOPEThesis] 
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Figure  13.  TINYSCOPE  Activity  Plan 
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Long  Range  Planning  is  performed  to  optimize  use 
of  the  spacecraft  and  minimize  scheduling  conflicts  due  to 
planned  maintenance  operations . 

b.  Mission  Execution 

The  flight  operations  element  of  the  Mission 
Operations  Center  performs  mission  execution  functions. 
The  activity  plans  that  are  generated  by  the  activity 
planning  element  are  converted  into  command  loads  for 
uplink  to  the  spacecraft.  Command  loads  may  contain  event 
commands,  which  instruct  the  spacecraft  to  collect  an  image 
of  a  specific  location  at  a  given  time,  or  they  may  be 
system  commands .  System  commands  are  instructions  for  the 
spacecraft  to  perform  a  non-collection  task.  Examples  of 
system  commands  include  instructions  to  transmit  stored 
data,  acknowledgements  that  files  are  have  been  received, 
commands  to  unload  momentum  and  the  like. 

TINYSCOPE  is  being  developed  as  a  demonstration 
of  immediately  available  satellite  imagery  tasking.  This 
requires  that  event  commands  may  be  transmitted  in  real 
time  and  executed  immediately.  Real-time  event  commands 
are  the  primary  type  of  command  for  the  TINYSCOPE  system. 
System  commands  may  also  be  used  real-time.  When  multiple 
real-time  commands  are  sent  to  the  satellite,  they  will  be 
grouped  into  a  real-time  command  script  and  transmitted  as 
a  batch. 

It  may  also  be  necessary  for  the  satellite  to 

store  cued  commands  to  image  locations  that  are  not  in  the 

access  footprint  of  the  NPS  ground  station.  In  this  case, 

a  stored  event  command  will  be  used.  Stored  command 

sequences  are  a  collection  of  stored  event  and  system 
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commands  that  will  be  executed  at  a  later  point.  Each 
command  contains  a  time  tag  to  tell  the  satellite  processor 
at  what  time  to  execute  the  command. 


A  final  type  of  command  that  may  be  used  is  the 
software  update  command.  Software  update  commands  load 
updated  databases  or  software  patches  to  the  satellite 
processor.  These  might  include  updates  to  star  databases , 
ephemeris  tables  or  corrections  to  flight  software. 

Regardless  of  the  type  of  command  that  is  being 
sent  to  the  satellite,  it  must  be  reviewed  and  then  tested 
on  a  software  model  of  the  fight  system.  Once  a  command 
sequence  or  real-time  script  has  been  validated,  it  will  be 
given  an  authentication  tag  by  the  simulation  software. 
Upon  uplink  the  satellite  will  verify  the  authentication 
tag  prior  to  executing  any  command.  Validated  and 

authenticated  command  files  will  be  sent  to  the  ground 
station  computer  and  will  be  transmitted  automatically 
following  contact  with  the  spacecraft. 

c.  Post-Mission  Operations 

Following  a  successful  contact  with  the  ground 
station,  telemetry  and  imagery  data  that  was  broadcast  by 
the  spacecraft  will  be  transmitted  automatically  to  the 
flight  operations  element.  Files  will  be  checked  for 
integrity  and  then  relayed  to  the  data  management  element. 

Engineering  and  telemetry  data  will  be  processed 
in  the  flight  operations  element  and  simultaneously 
archived  by  the  data  management  element.  The  flight 
operations  element  will  analyze  telemetry  logs  to  monitor 
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the  spacecraft's  state  of  health,  discover  anomalies  and 
identify  trends  that  may  degrade  operations. 

Mission  data  will  be  passed  to  the  data 
management  element  for  processing  and  archiving.  Raw 
copies  of  the  image  will  be  stored  in  a  separate  image 
database  from  images  that  have  been  processed.  Images  that 
were  collected  following  an  accepted  research  proposal  will 
be  provided  to  the  researcher  in  raw  format.  Public  access 
to  processed  images  may  be  available  via  the  internet  at 
the  discretion  of  the  university.  Raw  data  may  also  be 
made  available  for  a  fee  to  defray  processing  expenses. 
Occasionally  the  flight  operations  center  will  review  raw 
images  to  identify  CMOS  pixels  that  are  not  functioning 
properly.  Pixel  information  will  be  passed  to  data 

processors  to  aid  in  removal  of  incorrect  information. 

3 .  Launch  and  Early  Operations 

Launch  and  early  operations  (L&EO)  includes  launch, 
activation  and  commissioning. 

a.  Launch  Operations 

Launch  Operations  begin  at  lift-off  and  end  when 
the  spacecraft  has  been  ejected  from  the  CubeSat  deployer. 
CubeSats  are  typically  secondary  payloads  and  launch 
opportunities  in  a  particular  orbit  are  not  guaranteed. 
Secondary  payloads  have  additional  constraints  that  are 
required  as  well.  During  launch  operations  the  spacecraft 
will  be  safed  and  unpowered.  This  requires  that  the 
spacecraft  have  a  means  of  self-activation. 
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jb. 


Activation  Sequence 


The  TINYSCOPE  spacecraft  will  be  activated  by  the 
release  of  a  spring-loaded  contact  pin  when  it  is  pushed 
from  the  deployment  assembly.  Activation  will  initiate  a 
sequence  of  events,  as  shown  in  Figure  14.  The  critical 
events  in  the  sequence  are  depicted  in  bold  outlines  and 
include:  attitude  stabilization ,  solar  power  generation, 

and  initiation  of  low  rate  communications. 

c.  Commissioning 

Following  activation,  the  TINYSCOPE  spacecraft 
will  enter  a  commissioning  phase  during  which  all  of  the 
spacecraft  subsystems  will  undergo  testing  to  ensure  full 
operability  and  the  payload  will  be  powered  on  for  the 
first  time.  The  objective  of  commissioning  is  to  achieve  a 
status  that  allows  normal  operations. 

The  first  task  in  the  commissioning  phase  is 
gaining  fine  pointing  control  of  the  spacecraft.  This 
requires  several  steps.  Initially,  the  spacecraft  will 
perform  a  series  of  predefined  momentum  adjustments  to 
confirm  and  refine  the  spacecraft's  moments  of  inertia. 
The  refined  MOIs  will  be  fed  into  the  spacecraft  control 
algorithms  during  a  software  update.  The  various 

instruments  used  for  attitude  and  position  knowledge  will 
be  calibrated  and  ephemeris  will  be  updated.  Finally, 
attitude  control  parameters  will  be  finely  calibrated  by 
using  a  series  of  slew  maneuvers  that  gradually  increase  in 
aggressiveness . 

A  second  task  that  will  be  performed 

simultaneously  during  commissioning  is  verification  and 
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calibration  of  bus  subsystems.  Power  generation, 
temperatures,  and  electrical  loads  will  be  monitored  to 
generate  baseline  profiles  for  the  spacecraft.  Autonomous 
operations  parameters,  fault  detection  triggers,  and  fault 
response  mechanisms  will  be  updated  as  necessary  based  on 
the  baseline  profiles.  Bit  error  rates  will  be  determined 
for  the  spacecraft  to  ground  communications  links  as  well. 

The  final  commissioning  task  is  activation, 
checkout,  and  performance  evaluation  of  the  optical 
payload.  Activation  will  occur  after  a  wait  period  to 
allow  out-gassing  to  occur.  The  camera  module  will  be 
powered  and  functional  tests  will  be  performed.  Electronic 
calibration  will  be  performed  to  ensure  the  health  of  the 
detection  lines.  Once  the  camera  is  determined  to  be 
operating  properly,  the  spacecraft  will  be  tasked  with  a 
series  of  reference  missions  to  determine  performance 
levels.  These  missions  will  use  a  variety  of  locations  to 
measure  pointing  accuracy,  uniformity  of  the  CMOS  detector 
response,  and  resolution. 
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Figure  14.  Spacecraft  Activation  Sequence 

48 


c. 


NORMAL  OPERATIONS 


1 .  Contact  Scenario 

a .  Objective 

This  scenario  describes  the  functions  performed 
during  a  standard  communications  contact  between  the 
TINYSCOPE  satellite  and  the  ground  station.  These 

functions  will  be  automated  during  nominal  passes. 

b.  Assumptions 

■  This  is  a  standard  pass  over  the  NPS  ground 

station.  Access  time  will  be  greater  than  4 
minutes . 

■  Satellite  ephemeris  at  ground  station  and 

on-board  is  accurate  to  within  two  and  one 
half  degrees. 

■  Satellite  beacon  and  S-band  radio  are 

operational . 

■  Command  script  has  been  developed, 

authenticated  and  has  been  received  by  the 
ground  station  computer. 

c.  Description 

Thirty  minutes  prior  to  contact  the  TINYSCOPE 
spacecraft  will  slew  to  point  the  high  gain  antenna  at  the 
ground  station  and  will  maintain  track.  The  ground  station 
antenna  will  steer  to  predicted  contact  point. 

Fifteen  minutes  prior  to  scheduled  contact  the 
spacecraft  will  begin  to  transmit  continuous  low  rate 
telemetry  data  through  the  omni-directional  antenna.  The 
ground  station  antenna  will  initiate  a  sweep  pattern  to 
acquire  the  beacon. 

Upon  acquisition  of  the  beacon,  the  ground 

station  will  begin  tracking  and  transmit  a  handshake 

49 


signal.  The  spacecraft  will  maneuver  as  necessary  and 
complete  the  handshake  with  the  S-band  radio  and  high  gain 
antenna.  The  beacon  will  then  cease  to  transmit. 
Following  handshake,  the  spacecraft  will  pass  real  time 
telemetry  to  the  ground  station.  The  ground  station  will 
upload  a  clock  synchronization  command  followed  by  the 
authenticated  command  script. 

A  typical  command  script  will  contain  a  command 
to  initiate  playback  and  a  new  command  load.  Playback  will 
begin  with  the  telemetry  log  followed  by  the  command 
sequence  data  and  mission  data.  Data  will  be  packetized  to 
protect  against  communications  disruption. 

Ninety  seconds  prior  to  the  contact  keyhole  time 
the  ground  station  will  send  a  command  to  halt  playback  and 
begin  beacon  operations.  The  handshake  process  will 
restart  as  the  keyhole  period  ends  and  another  playback 
command  will  be  sent.  This  sequence  will  occur  again  at  the 
end  of  the  contact  period. 

After  completion  of  playback  or  loss  of  contact, 
the  satellite  will  terminate  the  S-band  transmission  and 
resume  normal  operations.  The  ground  station  antenna  will 
steer  back  to  its  stowed  position  and  data  will  be 
transferred  to  the  flight  operations  element. 
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2 .  Real  Time  Collection  Scenario 

a.  Objective 

The  primary  mission  of  TINYSCOPE  is  real-time 
image  collection.  This  scenario  describes  the  system's 
performance  when  a  real-time  event  command  script  is 
uplinked  following  contact. 

Jb.  Assumptions 

■  The  flight  operations  element  has 
constructed  an  authenticated  command  load 
sequence  that  has  been  received  by  the 
ground  station  computer. 

■  Spacecraft  and  ground  station  have  performed 
handshake  and  spacecraft  is  prepared  for 
command  script  uplink. 

c.  Description 

The  real  time  collection  profile  begins  with  the 
uplink  of  the  command  script  to  the  spacecraft.  Real  time 
command  scripts  contain  an  immediate  execution  tag.  Upon 
recognition  of  this  tag,  the  spacecraft  will  terminate  S- 
band  transmission  and  resume  low  rate  telemetry  broadcast 
by  the  beacon.  This  allows  the  flight  operations  element 
to  monitor  the  mission. 

The  spacecraft  processor  determines  the  required 
momentum  adjustments  to  maneuver  the  spacecraft  to  point  at 
the  desired  location  and  executes  the  maneuver. 
Simultaneously  the  camera  instrumentation  will  be 
activated.  As  the  spacecraft  approaches  the  correct 

orientation  the  adjustments  become  finer  to  allow  the 
spacecraft  to  settle.  Additional  fine  adjustments  will  be 
conducted  during  camera  operation  to  reduce  motion  blur. 
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The  camera  will  record  the  target  image  onto  the  solid 
state  recorder.  The  spacecraft  will  repeat  this  sequence 
for  additional  tasked  images  and  then  return  to  an 
orientation  to  communicate  with  the  ground  station. 

The  S-band  radio  will  be  reactivated  after  the 
handshake  with  the  ground  station  and  the  contact  scenario 
will  resume. 
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Flow  Diagram 
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3. 


Programmed  Collection  Scenario 


a.  Objective 

This  scenario  describes  the  system''  s  performance 
when  a  stored  command  sequence  is  uplinked  following 
contact . 

b.  Assumptions 

■  The  flight  operations  element  has  constructed 
an  authenticated  command  load  sequence  that 
has  been  uplinked  to  the  spacecraft. 

c.  Description 

Execution  of  a  stored  command  sequence  begins 
after  the  termination  of  the  contact  scenario.  The 

spacecraft  begins  by  ordering  the  commands  based  on  the 
time  tags  in  the  command  sequence  and  discarding  any 
commands  that  have  expired. 

The  spacecraft  then  identifies  the  command  with 
the  earliest  time  tag.  If  the  time  to  event  is  greater 
than  fifteen  minutes,  then  the  spacecraft  will  execute  a 
maneuver  to  a  sun-soaking  orientation.  Fifteen  minutes 
prior  to  execution  of  a  command,  the  spacecraft  will  begin 
momentum  adjustments  to  point  the  spacecraft  at  the  target. 
As  the  spacecraft  approaches  the  correct  orientation,  the 
adjustments  become  finer  to  allow  the  spacecraft  to  settle. 
Additional  fine  adjustments  will  be  conducted  during  camera 
operation  to  reduce  motion  blur.  The  camera  will  record 
the  target  image  onto  the  solid  state  recorder.  The 
spacecraft  will  repeat  this  sequence  for  additional  stored 
events,  returning  to  a  sun-soaking  orientation  as 
allowable . 
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Figure  17.  Programmed  Collection  Scenario 
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4. 


Momentum  Management  Scenario 


a.  Objective 

This  scenario  describes  the  process  required  to 
unload  momentum  from  the  reaction  wheels  as  they  become 
saturated . 

b.  Assumptions 

■  Momentum  unloading  may  occur  autonomously  or 
as  part  of  a  command  load. 

■  No  image  collection  will  take  place  while 
the  spacecraft  is  unloading  momentum 

c.  Description 

The  reaction  wheels  on  the  TINYSCOPE  spacecraft 
will  become  saturated  as  the  wheels  reach  their  maximum 
spin  rates.  Momentum  unloading  will  occur  when  any 

reaction  wheel  becomes  80%  saturated.  Magneto-torquers 
will  be  used  to  dump  the  momentum. 

The  momentum  management  scenario  is  started  by  a 
command  from  the  ground  or  when  telemetry  indicates  that 
the  saturation  threshold  has  been  met.  Collection 

operations  will  be  suspended.  Stored  commands  will  be 
reordered  if  possible.  Real  time  commands  will  be 
discarded  and  an  error  will  be  annotated  on  the  telemetry 
log . 

The  magneto-torquer  orthogonal  to  the  most 
saturated  reaction  wheel  will  be  activated.  That  reaction 
wheel  will  then  be  decelerated  to  zero.  This  sequence  will 
be  followed  by  the  next  two  reaction  wheels.  Following 
unloading,  the  spacecraft  will  resume  normal  operations. 
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Momentum  Management  Scenario 
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5. 


Software  Update  Scenario 


a.  Objective 

This  scenario  describes  the  process  of  updating 
the  spacecraft's  flight  software.  A  software  update  may  be 
required  to  correct  a  bug  or  to  update  the  star  tracker 
database  or  ephemeris  tables. 

Jb.  Assumptions 

■  The  processor  being  updated  is  functioning 

properly . 

■  The  software  update  has  been  tested  on  the 

software  simulator. 

■  Spacecraft  and  ground  station  have  performed 
handshake  and  spacecraft  is  prepared  for 
command  script  uplink. 

c.  Description 

Software  uploads  have  the  potential  to  be 
catastrophic.  The  TINYSCOPE  solid  state  recorder  has  two 

partitions  dedicated  to  flight  software  integrity.  The 
partition  in  which  the  current  version  of  flight  software 
being  used  by  the  processor  resides  is  designated  as  the 

primary  partition.  The  secondary  partition  alternately 
stores  a  past  version  of  a  future  version. 

Software  update  procedures  begin  with  the  uplink 
of  a  preparatory  command  to  delete  the  secondary  partition. 
The  new  flight  software  is  then  transmitted  to  the 
spacecraft  and  stored  in  the  secondary  partition. 

Software  update  files  are  transmitted  in  packet 
segments  that  include  cyclic  redundancy  checks  (CRC)  at  the 
frame  level.  Additionally,  a  file  checksum  is  used  to 
compare  the  completed  file  on  the  spacecraft  with  that  on 
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the  ground.  If  a  CRC  fails,  the  entire  packet  is 
retransmitted.  If  a  file  checksum  fails,  the  entire  file 
will  be  retransmitted. 

Once  the  software  update  is  in  pace  in  the 
secondary  partition  and  integrity  checks  have  passed,  a 
command  to  execute  memory  load  will  be  transmitted.  The 
update  will  be  copied  completely  to  the  processor  memory 
load  buffer  and  integrity  checks  will  be  performed  again. 
If  a  check  fails  the  load  buffer  will  be  erased  and  an 
error  report  sent  to  the  telemetry  log  and  the  ground 
station.  If  the  integrity  checks  pass,  the  memory  load 
will  continue.  After  the  memory  load  is  complete  the  load 
buffer  will  be  erased  and  a  completion  message  will  be  sent 
to  the  telemetry  log  and  to  the  ground  station.  The 
processor  will  then  run  a  diagnostic  self-test  to  ensure 
full  functionality.  Upon  successful  completion  of  the 
test,  the  secondary  partition  will  be  designated  as  the 
primary  and  vice  versa. 

If  the  processor  fails  a  diagnostic  test  or  the 
software  is  discovered  to  have  errors,  the  previous  version 
may  be  recovered  from  the  secondary  partition  without 
contact  with  the  ground. 
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d. 


Flow  Diagram 
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Figure  19. 


D. 


CONTINGENCY  OPERATIONS 


1 .  Fault  Detection 

a .  Objective 

The  flight  processor  monitors  each  subsystem' s 
operational  status  to  record  in  the  telemetry  log  and  to 
check  for  anomalies.  If  an  anomaly  is  discovered,  it  may 
require  the  satellite  to  end  normal  operations  to  protect 
the  subsystem  from  damage.  This  scenario  describes  how  the 
processor  monitors  and  examines  the  subsystems. 

b.  Assumptions 

■  The  spacecraft  is  operating  in  normal 
operations  mode. 

c.  Description 

The  flight  processor  automatically  responds  to 
anomalies  on  the  spacecraft.  The  response  to  a  given 
anomaly  has  usually  been  predetermined  and  tested  prior  to 
launch.  Anomaly  responses  are  integral  to  the  flight 
software  and  changes  to  responses  will  require  a  software 
update.  In  the  event  that  an  anomaly  occurs  that  the 
spacecraft  does  not  have  a  programmed  response  for,  the 
processor  will  place  the  spacecraft  in  emergency  mode. 

Anomalies  that  have  been  planned  for  may  be 
responded  to  by  taking  the  reporting  subsystem  offline, 
placing  the  satellite  in  safe  mode  or  by  simply  reporting 
the  anomaly  to  the  telemetry  log.  The  severity  of  the 
anomaly  will  typically  dictate  the  action  taken. 

A  subsystem  may  be  taken  offline  when  there  is  a 

condition  that  will  cause  further  damage  to  the  subsystem 

or  the  spacecraft  if  not  corrected.  An  example  of  this 
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type  of  condition  would  be  a  temperature  or  voltage 
measurement  that  is  too  high  or  low  causing  a  component  to 
overheat  or  drain  power  from  the  spacecraft. 


The  satellite  will  be  placed  in  a  safe  mode  when 
failure  to  respond  will  endanger  the  mission.  This  may 
occur  when  an  anomaly  involves  more  than  a  single  subsystem 
or  when  the  anomaly  indicates  that  a  reaction  wheel  of  the 
spacecraft  is  out  of  limits. 

Minor  anomalies  or  pseudo-anomalies  may  require 
only  that  the  anomaly  is  reported.  Example  cases  of  a 
report  only  anomaly  may  include  failure  of  the  battery  to 
fully  recharge  or  a  slow  rise  or  fall  in  temperature  that 
is  creating  a  thermal  imbalance. 

Anomalies  that  involve  the  safing  of  the 
satellite  or  a  subsystem  must  be  resolved  before  normal 
operations  can  begin  again.  These  anomalies  will  be 
analyzed  by  the  flight  operations  element  and  corrective 
actions  will  be  fully  tested  on  simulator  software  before 
implementation . 
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d.  Flow  Diagram 
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2 .  Power  Management  Failure  Scenario 

a.  Objective 

This  scenario  describes  the  autonomous  response 
of  the  spacecraft  when  the  EPS  reports  a  low  power 
condition . 

b.  Assumptions 

■  The  spacecraft  is  operating  in  normal 

operations  mode. 

■  The  EPS,  solar  array  and  batteries  are  fully 
functional . 

c.  Description 

The  EPS  on  TINYSCOPE  continuously  monitors  the 
battery  state  of  charge  and  the  power  drawn  by  the 
spacecraft's  subsystems.  A  low  power  contingency  may 
occur,  if  the  spacecraft  has  been  performing  excessive 
attitude  maneuvers  in  support  of  normal  operations  and  has 
not  maintained  an  orientation  that  allows  power  generation. 
When  the  batteries  reach  a  low  state  of  charge,  a  fault 
will  be  reported  to  initiate  the  automatic  response.  The 
spacecraft  will  cease  to  execute  event  commands  and  will  go 
to  SAFE  Mode.  The  EPS  will  shunt  all  power  to  the 
batteries  in  an  effort  to  allow  them  to  recharge.  The  EPS 
will  automatically  restore  normal  power  when  the  battery 
state  of  charge  recovers  satisfactorily. 

A  more  severe  fault  is  generated  if  the  state  of 
charge  continues  to  fall  to  a  critical  level.  At  this 
point,  the  spacecraft  will  go  to  EMERGENCY  mode.  Recovery 
from  EMERGENCY  mode  requires  intervention  from  the  flight 
operations  element. 
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3 .  Loss  of  Low-Rate  Telemetry  Beacon  Scenario 

a.  Objective 

This  scenario  describes  the  procedures  taken  when 
the  low  rate  telemetry  beacon  fails  resulting  in  the 
inability  to  acquire  a  signal  for  the  GS  antenna  to  lock 
onto . 


b.  Assumptions 

■  There  is  a  scheduled  contact  with  the  ground 
station.  Spacecraft  was  operating  normally 
during  last  contact. 

■  Ground  station  antenna  and  computer  are 
operational  and  pointing  correctly. 

■  All  other  spacecraft  systems  are  functioning 
properly . 

c.  Description 

As  in  the  contact  scenario,  the  GS  antenna  will 
steer  to  and  point  at  the  location  where  the  spacecraft  is 
predicted  to  be.  During  a  nominal  contact,  the  antenna 
would  acquire  the  beacon  signal  and  use  it  to  lock  onto  the 
satellite  to  enable  high  gain  antenna  communications.  When 
the  beacon  signal  cannot  be  located  using  the  standard 
search  pattern,  this  procedure  is  used. 

The  flight  operations  element  will  verify  that 
the  GS  is  operational  and  is  not  at  fault  for  the  lack  of 
acquisition.  Pointing  angles  will  be  recalculated  and 
verified  in  the  GS  computer.  Command  logs  from  the 
previous  contact  will  be  examined  to  ensure  that  the 
problem  was  not  induced  by  a  command.  Telemetry  logs  will 
be  reviewed  for  anomalous  conditions  and  to  ensure  that 
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ephemeris  data  is  correct.  If  the  condition  remains,  the 
fault  will  be  assumed  to  reside  with  the  spacecraft. 

The  GS  will  transmit  a  command  to  the  spacecraft 
to  activate  the  S-band  transmitter  and  high  gain  antenna 
and  commence  downlink  of  telemetry  data.  This  command  will 
be  repeated  during  subsequent  passes  until  communications 
with  the  spacecraft  is  restored.  Simultaneously f  the 
flight  operations  element  will  begin  developing  a  command 
load  sequence  to  bypass  the  beacon  and  omni-directional 
antenna  and  utilize  the  S-band  radio  and  high  gain  antenna 
for  telemetry  broadcast.  Once  communications  can  be 
restored,  the  alternate  contact  sequence  will  be  used  until 
the  anomaly  can  be  corrected. 
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d.  Flow  Diagram 
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4 .  Loss  of  Command  Ability  Scenario 

a.  Objective 

This  scenario  describes  the  procedures  taken  when 
the  S-band  radio  or  high  gain  antenna  fail  resulting  in  a 
loss  of  ability  to  command  the  spacecraft. 

b.  Assumptions 

■  The  spacecraft  is  operating  in  normal 
operations  mode. 

■  Beacon  signal  has  been  acquired  and  GS 
antenna  is  locked  on  the  satellite. 

■  Last  contact  with  spacecraft  was  nominal. 

c.  Description 

The  S-Band  radio  and  high  gain  antenna  are  the 
primary  means  of  communication  with  the  TINYSCOPE 
spacecraft.  Should  one  or  both  fail,  the  spacecraft  may  be 
commanded  through  the  low  rate  telemetry  beacon.  It  is 
also  possible  for  the  spacecraft  to  transmit  mission  data 
through  the  beacon,  but  the  data  rates  would  be  sub- 
optimal  . 

During  a  nominal  contact  scenario,  the  ground 
station  will  lock  onto  the  satellite  using  the  beacon  and 
then  upload  commands  and  download  data  using  the  S-band 
radio  and  high  gain  antenna.  Indications  that  there  is  an 
anomaly  with  these  components  may  come  through  a 
communications  handshake  failure. 

When  an  anomaly  exists,  the  flight  operations 
will  first  verify  that  the  ground  station  is  operational 
and  is  transmitting  in  the  appropriate  band  and  frequency. 
If  the  problem  persists,  a  series  of  innocuous  command  will 


70 


be  transmitted  to  the  spacecraft  to  determine  if  the 
spacecraft  can  receive  transmissions.  The  low  rate 
telemetry  being  broadcast  by  the  beacon  should  change  based 
on  the  commands  that  were  sent. 

In  the  event  of  a  transmit  only  failure,  the 
satellite  will  be  commanded  to  downlink  the  telemetry  and 
command  sequence  logs  through  the  beacon  and  will  be  placed 
in  SAFE  mode.  Anomaly  investigation  and  fault  recovery 
procedures  will  be  implemented. 

A  lack  of  change  in  the  telemetry  following  the 
test  commands  indicates  that  there  is  a  receive  failure.  A 
hardware  command  will  be  sent  to  the  beacon  radio  to  send  a 
fault  code  to  the  processor.  The  processor  will  then  use 
its  programmed  response  to  deactivate  the  S-band  radio  and 
transmit  and  receive  using  only  the  beacon  and  omni¬ 
directional  antenna.  The  satellite  will  then  be  placed  in 
SAFE  mode  and  anomaly  investigation  and  fault  recovery  will 
begin . 
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Flow  Diagram 
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Figure  23.  Command  Failure  Scenario 
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E.  INTEGRATION  AND  TEST 

1 .  System  Integration  and  Functional  Tests 

The  TINYSCOPE  satellite  will  undergo  integration  and 
testing  in  a  Class  6  (ISO)  clean  room  to  ensure  the 
spacecraft  is  not  damaged  by  particulates.  Equally 
important  is  that  working  in  a  clean  room  environment 
impresses  upon  students  and  others  that  the  processes  and 
activities  are  now  such  that  a  higher  level  of  attention 
and  consequence  must  be  kept  in  mind  while  working  with  the 
hardware.  Integration  begins  with  the  mating  of  the 
payload  to  the  bus  assembly  and  subsequent  alignment.  Mass 
models  of  the  solar  arrays  will  be  added  for  some  testing. 
This  is  Stage  1  for  testing  purposes.  At  Stage  1,  the 
satellite  will  undergo  a  functionality  test  of  all  the 
mechanisms.  The  ADCS  will  be  tested  using  simulated  state 
vectors  to  ensure  proper  motion  of  the  reaction  wheels.  The 
spring-loaded  activation  switch  will  be  tested  to  ensure 
proper  operation  and  solar  array  hinges  and  actuators  will 
be  tested.  A  telemetry  check  will  be  performed  using 
simulated  data.  The  satellite  will  be  placed  in  the  three- 
axis  simulator  and  control  algorithms  and  moments  of 
inertia  for  both  deployed  and  non-deployed  solar  panels 
will  be  verified.  Finally,  the  systems  fault  detection  and 
responses  will  be  tested  using  induced  faults. 

The  solar  array  panels  will  be  integrated  with  the 
system  for  Stage  2  testing.  During  this  stage,  electrical 
interfaces  will  be  verified  and  environmental  testing  will 
occur . 
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2 .  System  Environmental  Testing 

Environmental  testing  for  the  spacecraft  will  consist 
of  thermal  vacuum  testing,  electromagnetic  interference 
testing  (EMI),  and  random  vibration  testing. 

Thermal  vacuum  testing  will  be  used  to  identify 
workmanship  deficiencies  under  flight-like  conditions  and 
to  screen  for  out-gassing  and  current  arcing. 

EMI  testing  will  verify  compatibility  of  the 
subsystems'  radiated  emissions.  During  this  test,  each 
subsystem  will  be  operated  in  its  most  noisy  state  to 
determine  interference  with  other  subsystems . 

Random  vibration  testing  will  verify  the  system's 
ability  to  withstand  the  vibroacoustic  environment  of  the 
launch.  It  will  also  help  to  identify  workmanship 
deficiencies  [15]. 
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IV.  CONCLUSION 


A.  SUMMARY 

The  program  management  and  systems  engineering 
challenges  and  lessons  outlined  in  this  thesis  should  be  a 
useful  guide  for  future  projects  at  the  Naval  Postgraduate 
School.  In  the  author's  opinion,  the  success  of  a  project 
is  determined  largely  in  the  planning  stage. 

A  good  program  will  have  a  clear  end  state  and  the 
milestones  required  to  achieve  that  end  will  be  defined  in 
a  framework  document.  System  requirements  must  be  clear, 
concise,  and  verifiable.  Cost,  performance,  schedule  and 
risks  must  be  monitored  continuously  throughout  the  project 
and  in  accordance  with  the  framework.  This  program  has 
been  an  excellent  way  to  exercise  the  tenants  of  systems 
engineering  and  project  management  in  an  environment  that 
fosters  learning. 

B .  FUTURE  WORK 

The  TINYSCOPE  program  has  been  an  excellent  learning 
experience.  A  tremendous  amount  of  work  has  been  conducted 
by  the  TINYSCOPE  team,  but  much  still  remains  to  be  done. 

There  are  several  management  functions  of  the  program 
that  still  require  direction.  The  Systems  Engineering 
Management  Plan  will  provide  a  foundation  for  the 
implementation  of  the  engineering  effort  by  identifying  the 
deliverables  during  each  phase  and  defining  the  quality 
assurance  plan  and  methodology  for  the  project.  It  clearly 
outlines  individual  roles  and  responsibilities  to  ensure 
synergy  among  the  work  force.  The  Software  Management  Plan 
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defines  the  format  of  communications  between  the  various 
subsystems.  It  will  drive  the  development  of  the  on-board 
algorithms,  fault  detection  and  recovery  schemes,  and 
authentication  protocols  for  the  system. 

A  ground  system  still  needs  to  be  developed  to  manage 
communications  with  the  spacecraft,  data  management 
functions,  and  flight  operations.  The  author  hopes  that 
development  will  be  somewhat  simplified  by  the  effort  given 
in  this  thesis  to  define  the  flow  of  operations. 

Finally,  there  is  much  work  that  remains  in  the  design 
and  development  of  the  spacecraft  bus  and  in  the  testing 
and  integration  of  the  various  subsystems.  Each  of  the  bus 
subsystems  and  the  payload  will  require  environmental  and 
functional  tests  and  will  require  modifications  to 
integrate  with  the  spacecraft.  The  bulk  of  the  command 
software  and  any  processing  software  that  may  be  used  must 
be  engineered  and  coded.  Following  integration  of  the 
subsystems,  the  satellite  will  have  to  undergo  a  full 
battery  of  functional  and  environmental  tests  to  ensure 
that  it  will  operate  as  planned. 
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1  PROJECT  OVERVIEW 

1 . 1  Introduction 

The  TINYSCOPE  Project  Plan  describes  the  activities 
required  to  implement  the  flight  of  the  technology 
demonstrator  spacecraft.  The  TINYSCOPE  mission  will  be 
conducted  in  a  relevant  space  environment  as  defined  for  a 
Technology  Readiness  Level  (TRL)  of  8.  TINYSCOPE  will  both 
demonstrate  new  spacecraft  technologies  and  implement 
proven  technologies . 

The  TINYSCOPE  project  is  primarily  used  as  a  vehicle 
for  student  research  into  attitude  dynamics,  guidance, 
navigation  and  controls  algorithms  and  mission  operations. 
Additionally,  student  researchers  are  gaining  hands-on 
experience  with  design,  construction  and  integration  of 
satellite  hardware.  The  current  schedule  plan  is  to 
deliver  hardware  ready  to  fly  by  December  2011.  Due  to 
the  project's  size,  scope,  cost  and  schedule,  the  risk 
constraints  for  the  project  are  somewhat  relaxed  when 
compared  to  traditional  space  flight.  As  such 
qualification  testing  is  required  only  for  verification  of 
safety  compliance  and  interface  compatibility  with  the 
launch  vehicle  adapter.  Acceptance  tests  will  be  conducted 
to  ensure  that  critical  performance  parameters  are  likely 
to  be  achieved.  Project  reviews  will  be  performed  in  the 
context  of  a  technology  demonstration  test. 

1.2  Objectives 

TINYSCOPE  is  an  effort  to  develop  a  low-cost  and 
easily  replaceable  imaging  spacecraft  that  can  produce 
tactically  relevant  imagery  data.  Tactical  requirements  in 
this  context  would  emphasize  "good  enough"  image  resolution 
with  a  rapid-response  tasking  loop  and  high  revisit  rate. 
The  TINYSCOPE  project  intends  to  demonstrate  the  utility  of 
small,  risk  tolerant  spacecraft  for  this  purpose.  The 
objectives  of  the  TINYSCOPE  mission  are: 

A.  The  primary  objective  of  the  TINYSCOPE  program  is 
facilitation  of  student  education  at  the  Naval  Postgraduate 
School . 

B.  Launch  and  operate  one  TINYSCOPE  spacecraft 
capable  of  obtaining  images  of  a  tasked  target  along  a 
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predetermined  low  earth  orbit  and  transmitting  images  to  a 
known  stationary  ground  station  within  minutes  of  tasking. 

C.  Demonstrate  an  attitude  determination  and  control 
system  to  provide  accurate  and  agile  pointing  for 
nanosatellites . 

1.2.1  Performance  Measurement  System 

The  methodology  used  for  managing  the  TINYSCOPE 
Project  and  measuring  performance  will  be  to  monitor 
appropriate  status  indicators.  Monthly  updates  reporting 
on  risk  data  and  the  impact  on  mission  success  will  be 

generated  and  tracked.  The  following  categories  will  be 

examined  monthly  for  risk  impact. 

Cost 

Evaluate  how  the  project  budget  is  performing  against 
the  approved  Project  Plan  budget  and  FY  Actual  vs 

Planned  performance. 

Schedule 

Evaluate  how  the  project  schedule  is  performing  to 

ensure  major  milestones  and  the  project  delivery  dates 
approved  in  the  project  plan  are  met. 

Technical  Performance 

Evaluate  how  the  project  is  meeting  the  requirements 
documented  in  the  approved  project  plan. 

Management  Issues 

Evaluate  management  products/processes  and  other 
management  responsibilities  to  ensure  the  project  will 
meet  commitments . 

1.2.2  Mission  Success  Criteria 

Objective  1  -  Successful  implementation  and  execution 

of  the  project  plan  including  design,  construction, 
verification,  launch,  on-orbit  evaluation  and  delivery  of 
appropriate  ground  control  hardware. 

Objective  2/3  -  This  system  will  have  the  ability  to 

detumble  and  stabilize,  point  to  earth  and  subsequently 
image  and  download  to  a  ground  station. 
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1.2.3  Extended  Mission  Success  Criteria 

Objective  1  -  Successful  completion  of  the 
development,  test  and  integration  activities  results  in 
hardware  delivered  for  launch  by  December  2012. 

Objective  2  -  Ability  to  download  multiple  images  from 
a  single  orbital  pass  over  the  known  ground  station.  The 
spacecraft  will  continue  to  operate  and  perform  mission 
functions  for  a  period  of  three  months  following  launch. 

Objective  3  -  Ability  to  quickly  and  accurately  point 
to  a  specified  location  on  the  earth's  surface. 

1 . 3  Mission  Description  and  Technical  Approach 

TINYSCOPE  is  a  unique  spacecraft  with  experimental 
structural  and  pointing  requirements,  optics  and  software. 
Both  the  payload  and  bus  will  necessarily  consist  of 
technologies  with  various  levels  of  maturity  and  space 
heritage.  Therefore,  wherever  possible  it  is  necessary  to 
mitigate  risks  to  operational  success  and  to  schedule  by 
incorporating  commercially  viable  components,  with  a 
preference  for  flight  proven  technologies.  Development  of 
unique  subsystems  will  be  considered  on  a  case  by  case 
basis  and  will  only  be  attempted  when  more  mature  options 
are  not  viable  due  to  cost,  performance  or  schedule 
constraints.  TINYSCOPE  will  seek  to  exploit  the  advantages 
of  CubeSat  platforms  by  including  small  subsystems 
requiring  minimal  power,  mass,  volume,  and  cost  to  operate. 


1.4  Project  Management  and  Team  Structure 


Figure  24.  TINYSCOPE  Project  Team  Structure 
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1 . 5  Stakeholder  Definition 

The  objectives  of  the  TINYSCOPE  Project  are  intended 
to  provide  a  demonstration  of  the  capabilities  that  small 
satellites  can  provide  to  national  security  goals.  The 
project  is  a  direct  offshoot  of  thesis  work  performed  by 
Allen  Blocker  and  Chance  Litton  intended  to  further  the 
research  into  alternative  national  security  space 
architectures.  Therefore  the  customers  of  TINYSCOPE 

include : 

•  National  Reconnaissance  Office 

•  Air  Force  Research  Laboratory 

•  USSTRATCOM 

•  Office  of  Operationally  Responsive  Space 

•  External  space  technology  R&D,  commercial  and  academic 
organizations 
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2  PROJECT  BASELINE 

2 . 1  Requirements  Baseline 

The  hardware  shall  be  designed  and  built  to  meet  the 
bus,  payload,  mission  and  technology,  and  master  satellite 
interface  requirements  as  documented  in  the  Certification 
and  Acceptance  Requirements  Document  (CARD) .  The  technology 
hardware  shall  be  designed  to  meet  the  specifications  for 
the  interface  requirements  of  the  payload  subsystem  as  well 
as  the  interface  requirements  of  the  Spacecraft  Deployer 
and  Launch  Vehicle  provider.  Clarification  of  user 
requirements,  operations,  and  driving  technology  will  be 
performed  prior  to  the  Critical  Design  Review  (CDR) . 

2 . 2  Reference  Documents 

The  following  documents  are  reference  documents  for 
this  plan: 

Certification  and  Requirements  Document  NACL10-02-T 
Systems  Engineering  Management  Plan  NACL10-03-T 
Software  Management  Plan  NACL10-04-T 
TINYSCOPE  Master  Schedule  NACL10-05-T 
Mission  Operations  Plan  NACL10-06-T 
Master  Product  Breakdown  Structure  NACL10-07-T 
Contamination  Control  Plan  NACL10-08-T 
TINYSCOPE  Request  for  Research  Proposal  to  NRO 

2 . 3  Product  Breakdown  Structure 

The  TINYSCOPE  Project  has  three  primary  segments: 

•  Satellite  System  -  This  includes  both  the  Bus  and 
payload  systems.  The  payload  systems  specifically 
include  the  telescope,  image  detector,  associated 
software,  data  management  for  the  payload,  and 
supporting  systems.  The  Bus  systems  include 
communications  system,  flight  computer  and  software, 
power  generation  and  distribution,  attitude 
determination  and  control  systems,  and  structural 
systems,  including  thermal  management. 
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•  Mission  Operations  Systems  -  This  includes  spacecraft 
control  and  flight  test  support  Mission  Operations 
Center  (MMOC)  and  Ground  Station. 

•  Ground  Support  Systems  -  This  includes  quality 
assurance,  integrated  testing  and  verification,  and 
satellite  handling. 

•  Detailed  information  defining  each  of  the  segments  and 
related  subsystems  is  located  in  the  Master  Product 
Breakdown  Structure. 

2 . 4  Schedule  Baseline 

The  program  manager  and  the  TINYSCOPE  team  will  use 
this  schedules  for  evaluating,  managing,  and  reporting 
project  performance  with  respect  to  baseline  plans.  Lower 
level  schedules  will  be  developed  and  monitored  via  major 
milestones  and  interim  deliverables  to  be  determined  in 
those  detailed  development  schedules.  Variances  will  be 
addressed  as  program  risks  if  threatening  Major  Milestone 
delivery  dates. 


Major  Milestone  Date 


MRR 

Mission  Requirements  Review  and 

Baseline 

9/15/10 

PDR 

Preliminary  Design  Review 

TBD 

CDR 

Critical  Design  Review 

TBD 

FRR 

Flight  Readiness  Review 

TBD 

Flight  Hardware  Ship  to  Launch  Site 

TBD 

ORR 

Operations  Readiness  Review 

TBD 

Launch  Readiness  Date 

TBD 

2 . 5  Resource  Baseline 


FY  0  9 

Total  Funding 

Procurement 

45,000 

Labor 

33,000 

FY  10 

Procurement 

TBD 

Labor 

TBD 

FY  11 

Procurement 

TBD 

Staffing 

TBD 
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Approval  is  restricted  to  above  budget.  Any  deviation  from 
the  approved  budget  must  get  approval  from  both  Primary 
Investigators . 


3  PROJECT  CONTROL  PLANS 

3.1  Technical,  Schedule,  and  Cost  Control  Plan 

Phasing  will  conform  generally  to  the  proposal  for 
research  submitted  to  the  AS&T,  NRO  for  the  period  October 
1st,  2009  -  December  31st,  2010.  More  specifically,  the 
baseline  schedule  referenced  in  Section  2.5  of  the  Project 
Plan  outlines  the  timeline  of  milestones  and  reviews. 
Reviews  are  held  at  the  end  of  every  phase  as  the  control 
gate  to  end  each  phase  as  well  as  get  approval  to  proceed 
to  the  next  phase.  The  Systems  Engineering  Management  Plan 
explicitly  defines  all  deliverables  for  each  milestone.  The 
milestones  will  be  used  as  a  schedule  performance  metric 
with  a  recommended  corrective  action  scheduled  for  each 
milestone  past  due.  Lower  level  schedules  will  be  developed 
and  monitored  via  milestones  and  interim  deliverables  to  be 
determined  in  detailed  development  schedules.  Variances 
will  be  addressed  as  program  risks  if  threatening  milestone 
delivery  dates.  Cost  performance  metrics  will  consist  of 
planned  vs  actual  FY  budget  analysis  performed  monthly. 
Technical  requirements  will  be  reviewed  monthly  to  ensure 
that  each  segment  remains  on  track  to  meet  performance 
ob j ectives . 

3 . 2  Mission  Assurance  Plan 

TINYSCOPE  reliability  requirements  support  the 
characterization  of  the  program  as  a  short  hardware  life 
requirement,  low  complexity,  low  cost,  short  program 
duration,  and  economically  replaceable.  The  TINYSCOPE 
hardware  will  be  designed  to  operate  for  at  least  one 
complete  mission  cycle  (minimum  of  6  months)  including 
ground  operations  prior  to  flight.  The  launch  provider 
ground  safety  reviews  will  also  be  conducted  to  ensure 
compliance  with  their  mission  assurance  requirements. 

3 . 3  Risk  Management  Plan 

The  risk  management  strategy  for  the  TINYSCOPE  Project 
is  to  identify,  analyze,  plan,  track,  control,  communicate 
and  document  critical  areas  and  risk  events,  both  technical 
and  non-technical ,  and  take  necessary  action  to  manage  them 
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to  prevent  serious  cost,  schedule  or  performance  impacts. 
The  program  investigators  and  sponsors  acknowledge  and 
accept  the  high  risk  associated  with  a  technology 
demonstration  spacecraft.  Risk  information  will  be 
included  in  all  program  reviews  and  the  project  will  be 
continuously  monitored  for  areas  that  may  add  to  project 
risk  and  associated  mitigation  methods. 

3 . 4  Acquisition  Plan 

Standard  Naval  Postgraduate  School  procurement 
guidelines  will  be  followed  at  all  times. 

3 . 5  Systems  Engineering  Management  Plan 

The  Systems  Engineering  Management  Plan  explicitly 
defines  the  major  milestones  and  defines  all  deliverables 
for  each  milestone.  The  SEMP  is  tailored  to  the  TINYSCOPE 
project.  The  primary  function  of  the  SEMP  is  to  provide  the 
basis  for  implementing  the  technical  effort  and 
communicating  what  will  be  done,  by  whom,  when,  where,  cost 
drivers,  and  why  it  is  being  done.  The  SEMP  identifies  the 
roles  and  responsibility  interfaces  of  the  technical  effort 
and  how  those  interfaces  will  be  managed.  The  SEMP 
specifies  the  deliverables  for  each  phase  and  milestone  of 
the  project  so  that  control  gates  (major  reviews)  may  be 
passed  without  slippage  of  schedule  or  technical  progress. 
The  SEMP  also  defines  the  quality  assurance  plan  and 
methodology  for  the  project. 

3 . 6  Software  Management  Plan 

The  Software  Management  Plan  defines  the  format  of 
communications  between  the  various  subsystems  .  Where  any 
disparities  arise  between  the  Software  Management  Plan  and 
individual  subsystem  documentation,  the  SMP  take 
precedence . 

3 . 7  Review  Plan 

The  TINYSCOPE  Project  will  conduct  five  major  reviews 
prior  to  launch.  Dates  for  the  reviews  will  be  maintained 
in  the  TINYSCOPE  Master  Schedule.  The  major  reviews  will 
consist  of  the  following: 

MRR  -  Mission  Requirements  Review 

PDR  -  Preliminary  Design  Review 

CDR  -  Critical  Design  Review 

FRR  -  Flight  Readiness  Review 

ORR  -  Operation  Readiness  Review 
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The  purpose  of  the  reviews  are  outlined  in  the  Systems 
Engineering  Management  Plan  (SEMP) ,  but  are  generally  used 
as  control  gates  and  evaluation  of  the  progress  of  the 
flight  hardware.  Informal  hardware  development,  science 
development  and  test  readiness  reviews  will  be  conducted  as 
necessary  to  evaluate  interim  development  of  the  flight 
hardware . 

3 . 8  Mission  Operations  Plan 

The  TINYSCOPE  Mission  Operations  Plan  applies  to  the 
prototype  flight  of  the  TINYSCOPE  spacecraft  and  payload 
configuration.  This  plan  provides  the  top  level 
description  of  operations  necessary  to  execute  the  mission. 
The  plan  will  refer  to  specific  documented  procedures  for 
detailed  operations.  This  document  outlines  the  sequence  of 
events  and  operations  to  be  conducted  during  the  TINYSCOPE 
mission . 

3 . 9  Environmental  Management  Plan 

Environmental  management  of  the  spacecraft  will  be 
conducted  in  accordance  with  the  Contamination  Control 
Plan . 

3.10  Logistics  Plan 

The  TINYSCOPE  logistics  strategy  is  captured  in 
several  documents  including  the  SEMP  and  Mission  Operations 
Plan . 

3.11  Data  Management  Plan 

TINYSCOPE  documentation  and  mission  data  will  be 
maintained  by  the  Nanosat  Advanced  Concepts  Lab  for  the 
duration  of  the  spacecraft  mission  and  for  a  minimum  period 
of  3  years  following  completion  of  deorbit.  Access  to  data 
by  parties  external  to  the  United  States  Government  will  be 
handled  I AW  applicable  regulations  and  subject  to  the 
approval  of  the  director  of  the  Space  Systems  Academic 
Group.  Documentation  for  this  project  includes,  but  is  not 
limited  to,  management  plans,  specifications,  reports, 
technical  publications,  schematics,  drawings,  production 
and  inspection  records,  test  plans,  procedures  and  reports. 

3 . 12  Security  Plan 

The  TINYSCOPE  Project  will  ensure  security  and 
technology  protection  by  complying  with  applicable  Naval 
Postgraduate  School  policies  and  procedures.  The  TINYSCOPE 
Project  does  not  have  plans  to  transfer  or  ship  any 
products  outside  of  the  U.S.  All  Mission  Operations  and 
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handling  of  hardware  will  occur  at  designated  NASA  or  U.S 
Air  Force  facilities.  Wherever  possible  the  TINYSCOPE 
project  will  utilize  hardware  that  is  not  regulated  under 
export  control  laws.  However,  as  necessary  the  TINYSCOPE 
Project  will  adhere  to  the  the  Arms  Export  Control  Act 
(Title  22,  U.S.C.,  Sec  2751,  et  seq.)  and  the  Export 
Administration  Act  of  1979,  as  amended  (Title  50,  U.S.C., 
App .  2401  et  seq.) 
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APPENDIX  B  -CERTIFICATION  AND  REQUIREMENTS  DOCUMENT 


This  document  is  a  part  of  the  TINYSCOPE  Project 
Documentation,  controlled  by  the  TINYSCOPE  Project  Manager 
under  the  direction  of  the  Nanosat  Advanced  Concepts 
Laboratory  at  the  Naval  Postgraduate  School,  Monterey,  CA. 
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1  INTRODUCTION 

1 . 1  Purpose 

This  document  delineates  the  design,  construction, 
performance,  and  verification  requirements  for  the 
TINYSCOPE  Project.  This  document  additionally  defines  all 
tests,  analyses,  inspections  and  certification  methods 
required  for  all  applicable  flight  hardware.  Acceptance 
tests  will  be  conducted  to  ensure  that  critical  performance 
parameters  are  likely  to  be  achieved.  The  TINYSCOPE 
project  is  primarily  used  as  a  vehicle  for  student  research 
and  hands  on  experience  with  design,  construction  and 
integration  of  satellite  hardware.  Due  to  the  project's 
size,  scope,  cost  and  schedule,  the  risk  constraints  for 
the  project  are  somewhat  relaxed  when  compared  to 
traditional  space  flight.  As  such  qualification  testing  is 
required  only  for  verification  of  safety  compliance  and 
interface  compatibility  with  the  launch  vehicle  adapter. 
This  document  will  serve  as  both  a  planning  guide  and  a 
checklist  for  verifying  that  all  conditions  are  met  to 
include  design  certification,  acceptance  testing  and 
qualification  testing. 

1 . 2  Scope 

This  document  provides  the  baseline  requirements  for 
the  TINYSCOPE  spacecraft.  The  document  is  published  to 
provide  necessary  guidance  to  engineering  for  development 
of  system  design  solutions.  No  specific  design  solution  is 
specified  by  this  document. 

1.3  Definitions 

The  following  definitions  differentiate  between 
requirements  and  other  statements. 

Shall:  This  is  the  only  verb  used  for  the  binding 

requirements . 

Should/May:  These  verbs  are  used  for  stating  non¬ 

mandatory  goals. 

Will:  This  verb  is  used  for  stating  facts  or 

declaration  of  purpose. 

1 . 4  Responsibility  and  Change  Authority 

The  responsibility  for  the  development  of  this 
document  lies  with  the  TINYSCOPE  Project  Team  at  the  Naval 
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Postgraduate  School.  Derived  requirements  will  be  added  to 
this  document  following  a  quarterly  review  process  by  the 
Student  Program  Manager  and  Systems  Engineer  until  the 
Critical  Design  Review.  Following  CDR,  the  change 
authority  will  be  the  Student  Program  Manager  with 
concurrence  of  both  Principal  Investigators. 


2  APPLICABLE  AND  REFERENCE  DOCUMENTS 

2 . 1  Reference  Documents 

The  following  documents  are  reference  documents 
utilized  in  the  development  of  this  specification.  These 
documents  do  not  form  a  part  of  this  specification,  and  are 
not  controlled  by  their  reference  herein. 

2 . 2  Order  of  Precedence 

All  specifications,  standards,  exhibits,  drawings  or 
other  documents  that  are  invoked  as  "applicable"  in  this 
requirements  document  are  incorporated  as  cited.  All 
documents  that  are  referred  to  within  an  applicable 
document  are  considered  to  be  for  guidance  and  information 
only,  with  the  exception  of  Interface  Control  Documents 
that  shall  have  their  applicable  documents  considered  to  be 
incorporated  as  cited. 

2 . 3  Application  and  Traceability 

These  requirements  will  drive  the  derivation  of 
functional,  physical,  and  performance  specifications  for 
the  TINYSCOPE  project.  The  verification  of  these 
requirements  shall  certify  this  hardware  for  flight.  These 
requirements  shall  be  traceable  to  the  functions  and 
physical  configuration  items  that  meet  the  requirements. 


3  KEY  PERFORMANCE  PARAMETERS 

The  TINYSCOPE  Project  has  a  number  of  Key  Performance 
Parameters  (KPPs)  that  are  considered  critical  or  essential 
to  the  demonstration  of  an  effective  capability.  Each  KPP 
has  a  threshold,  representing  the  required  value,  and  an 
objective,  representing  the  desired  value. 

3.1  Mission  Duration  (KPP  1) 

The  satellite  shall  be  operational  for  a  period  of  six 
months  following  commissioning  (threshold)  and  should  be 
designed  for  operations  of  one  year  (objective) . 
Operational  is  defined  as  having  the  capability  to  receive 
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commands,  point  to  and  collect  images  of  given  targets,  and 
transmit  collected  data  to  the  ground  station. 

3.2  Earth  Imaging  Resolution  (KPP  2) 

The  satellite  shall  provide  panchromatic  images  of  the 
earth  in  the  visible  spectrum  with  an  effective  ground 
sampling  distance  of  5.0m  (threshold)  at  nadir  and  should 
be  designed  to  achieve  a  ground  sampling  distance  of  3.1m 
(objective) . 

3.3  Telescope  Field  of  View  (KPP  3) 

The  satellite  shall  have  a  swath  area  of  25  square 
kilometers  (threshold)  at  nadir  and  should  be  designed  to 
achieve  a  swath  area  of  50  square  kilometers  at  nadir 
(objective) . 

3.4  Image  Collection  Capacity  (KPP  4) 

The  satellite  shall  be  capable  of  collecting  and 
transmitting  to  an  accessible  ground  station,  two 
diametrically  opposed  off-nadir  images  (threshold)  in  a  ten 
degree  along  track  band.  The  satellite  should  be  capable 
of  collecting  and  transmitting  four  diametrically  opposed 
off-nadir  images  (objective)  in  a  ten  degree  along  track 
band. 

3.5  Geo-location  Accuracy  (KPP  5) 

The  satellite  shall  have  a  circular  ground  targeting 
error  of  less  than  200m  (threshold)  and  should  be  designed 
to  reduce  error  to  less  than  100m  (objective) . 


4  MISSION  HARDWARE  REQUIREMENTS 

4 . 1  Description 

4.1.1  Payload 

The  TINYSCOPE  payload  will  be  composed  of  the  telescope, 
camera  module,  all  associated  control  electronics,  all 
associated  mounting,  focusing,  and  alignment  hardware,  and 
required  software  to  meet  payload  performance  requirements. 

4.1.2  Spacecraft 

The  TINYSCOPE  spacecraft  provides  power  to  the  focal  plane 
array,  attitude  and  thermal  control,  command  and  data 
handling  and  communications. 

4.1.3  Communications  Ground  Station 

The  TINYSCOPE  ground  station  will  provide  an  intermittent 
link  between  the  satellite  and  the  flight  operations 
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element.  The  ground  station  consists  of  a  steerable 
antenna,  a  telemetry  tracking  receiver,  high  and  low 
frequency  synthesizers  and  computer  hardware  with  orbit 
propagation  software. 


4.1.4  Mission  Operations  Center 

The  Mission  Operations  Center  consists  of  three  operational 
elements:  flight  operations,  activity  planning  and  data 
management.  The  flight  operations  element  communicates 
with  and  controls  the  satellite  through  the  ground  station. 
Activity  planning  and  data  management  interact  with  the  end 
user  of  the  TINYSCOPE  product.  Figure  11  shows  how  each 
element  interacts  with  others . 


4.2  TINYSCOPE  Satellite  Assembly 

This  section  of  this  document 
functional,  performance,  physical, 
attributes,  characteristics,  requirements 
that  are  applicable  to  the  spacecraft. 


describes  all 
and  technical 
and  constraints 


4.2.1  Functional  Requirements 

TINYSCOPE  Payload  Subsystem 


TR-1  The  payload  shall  allow  on-board  imagery 
processing  and  compression  operations  to  be 
selectively  disabled. 


TR-2  The  payload  shall  meet  or  exceed  imagery 
requirements  at  all  points  in  orbit  and  in 
orientations  up  to  30  degrees  off-nadir  to  either 
side  of  the  orbital  plane. 

TR-3  The  payload  shall  remain  fully  functional  at  all 
points  in  orbit  and  in  orientations  up  to  30  degrees 
off-nadir  to  either  side  of  the  orbital  plane. 


TR-4  The  payload  shall  have  instrument  OFF,  SAFE  and 
OPERATIONAL  modes. 


TR-5  The  payload  shall  continue  to  collect  and 
transmit  telemetry  data  to  the  spacecraft  when  in 
SAFE  mode . 


TR-6  The  payload  shall  be  commanded  by  the 
spacecraft . 

TR-7  The  payload  shall  autonomously  enter  SAFE  mode 
in  the  event  of  direct  solar  illumination. 
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TR-8  The  payload  shall  be  in  OFF  mode  during  launch. 
TINYSCOPE  Bus  Subsystem 

TR-9  The  spacecraft  shall  autonomously  activate 
following  deployment  from  the  launch  vehicle. 

TR-10 The  spacecraft  shall  autonomously  maneuver  to  a 
stable  attitude  following  deployment  from  the  launch 
vehicle . 

TR-11  The  spacecraft  shall  autonomously  acquire  the 
sun  after  deployment  from  the  launch  vehicle. 

TR-12  The  spacecraft  shall  autonomously  enter  an 
attitude  that  maximizes  sun  exposure  after  attitude 
stabilization . 

TR-13  The  spacecraft  shall  be  capable  of  being 
commanded  into  any  operational  mode  from  the  ground. 

TR-14  The  spacecraft  shall  autonomously  transition  to 
SAFE  mode  upon  detection  of  any  fault  that  threatens 
the  health  and  safety  of  the  spacecraft. 

TR-15  The  spacecraft  shall  transition  out  of  SAFE 
mode  only  after  command  from  the  ground. 

TR-1 6  Spacecraft  autonomous  functions  shall  be 
performed  using  on-board  software. 

TR-1 7  The  spacecraft  shall  be  capable  of  initiating  a 
stored  response  to  pre-defined  telemetry  conditions. 

TR-1 8  The  spacecraft  shall  record  all  autonomous 
operations  to  the  telemetry  log. 

TR-1 9  The  spacecraft  shall  report  detection  of  out  of 
limit  conditions  for  monitored  systems  in  the 
telemetry  log. 

TR-20  The  spacecraft  shall  command  the  payload  to 
SAFE  mode  when  the  sun  is  predicted  to  enter  the 
field  of  view. 

Electrical  Power  Subsystem  (EPS) 

TR-21  The  EPS  shall  provide  a  single  point  ground 
within  the  power  subsystem. 
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TR-22  The  EPS  shall  provide  power  generation,  power 
control,  energy  storage  and  distribution  to  the 
Spacecraft . 

TR-23  The  EPS  shall  provide  conditioned  electrical 
power  for  all  Spacecraft  operational  modes  during 
eclipse  conditions. 

TR-24  The  EPS  shall  provide  battery  management  and 
load  shedding  control . 

TR-25  The  EPS  shall  distribute  direct  current  power 
to  the  loads  at  either  3.3  or  5  Volts. 

TR-26  The  spacecraft  shall  return  to  a  full  state  of 
charge  condition  in  the  battery  at  least  once  in 
five  orbits . 

TR-27  The  spacecraft  shall  be  capable  of  autonomously 
assuming  a  maximum  sun  exposure  orientation  upon 
detection  of  a  low  battery  charge  state. 

TR-28  The  spacecraft  shall  be  in  an  orientation  that 
maximizes  exposure  of  the  solar  array  to  the  sun 
while  in  SAFE  mode. 

TR-29  The  EPS  shall  provide  short  circuit  protection 
or  current  limitation  for  each  switchable  power 
circuit . 

TR-30  The  EPS  shall  provide  protection  from  over 
voltage  and  under  voltage  conditions . 

TR-31  The  spacecraft  shall  be  capable  of  being 
powered  from  an  external  source  while  on  the  ground 
with  or  without  batteries  installed. 

TR-32  The  EPS  shall  at  a  minimum  monitor  and  report 
in  telemetry  logs  the  switch  positions,  current,  and 
voltage  levels  for  each  circuit  at  the  power 
distribution  point. 

TR-33  The  spacecraft  battery  capacity  shall  be  1.25 
times  the  nominal  charge  /  discharge  profile  at  the 
end  of  the  spacecraft  design  life. 

TR-34  The  EPS  shall  be  capable  of  electrically 
bypassing  failed  battery  cells. 

Attitude  Control  and  Determination  Subsystem 
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TR-35  The  Spacecraft  shall  remain  thermally  stable, 
under  stable  attitude  control,  and  operationally 
functional  within  its  design  requirements  up  to  30 
degrees  off-nadir  on  either  side  of  the  orbit  plane. 

TR-36  The  Spacecraft  shall  use  the  UTC  time  as  the 
spacecraft  time  reference. 

TR-37  The  Spacecraft  shall  be  capable  of  receiving  a 
ground  base  Spacecraft  reference  time  and  time 
correction  coefficients. 

TR-38  The  Spacecraft  shall  generate  an  on-board 
ephemeris  based  on  the  Global  Positioning  System 
(GPS)  and  on-board  star  tracker. 

TR-39  The  Spacecraft  shall  include  the  GPS  carrier 
phase  and  pseudo  range  values  in  the  spacecraft 
ancillary  data  stream. 

TR-40  The  Spacecraft  shall  be  capable  of  receiving  a 
ground  based  ephemeris  update. 

TR-41  The  Spacecraft  shall  report  the  orbital 
position  and  velocity  once  per  second  in  the 
spacecraft  telemetry  log. 

Communications  Subsystem 

TR-42  The  Communications  Subsystem  shall  provide  two- 
way  RF  communications  for  uplink  of  command  and 
control  data  and  downlink  of  payload  data  and 
satellite  health  and  status  data. 

TR-43  The  Communications  Subsystem  shall  comply  with 
National  Telecommunications  and  Information 
Administration  (NTIA)  Spectrum  Standards. 

TR-44  The  Communications  Subsystem  shall  comply  with 
International  Telecommunication  Union  (ITU)  spectrum 
utilization  and  sharing  requirements. 

TR-45  The  Communications  Subsystem  shall  be  capable 
of  reception  of  ground  commands  while  in  any 
operational  mode. 

TR-4  6  The  Communications  Subsystem  shall  be  capable 
of  transmissions  in  any  operational  mode. 
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TR-47  The  Communications  Subsystem  shall  be  capable 
of  transmissions  in  any  orientation. 

TR-48  The  primary  communications  system  shall  be 
powered  at  all  times  except  when  the  satellite  is  in 
EMERGENCY  Mode. 

TR-4  9  The  primary  communications  system  shall  be 
capable  of  being  enabled  and  disabled  via  ground 
command. 

TR-50  The  primary  communications  system  shall  be  S- 
band. 

TR-51  The  command  uplink  shall  be  encrypted. 

TR-52  The  beacon  system  shall  provide  broadcasts  in 
compliance  with  FCC  Amateur  Radio  Regulations  (Part 
97)  . 

TR-53  The  beacon  system  shall  be  powered  from 
activation  through  the  life  of  the  mission. 

TR-54  The  beacon  system  shall  be  capable  of  being 
enabled  and  disabled  via  ground  command. 

TR-55  The  beacon  system  shall  be  capable  of  receiving 
commands  in  all  spacecraft  operational  modes. 

TR-56  The  beacon  system  shall  be  automatically 
disabled  after  21  days  in  the  event  that  no 
satellite  commands  are  received. 

TR-57  The  beacon  system  shall  be  designed  such  that 
its  broadcasts  can  be  reliably  received  with  a 
typical  OSCAR-class  amateur  radio  communication 
station . 

TR-58  The  beacon  system  shall  utilize  AX. 25  encoding 
protocol  using  1200  baud,  1  start  bit,  8  data  bits, 
and  1  stop  bit  format. 

TR-59  The  beacon  system  shall  broadcast  data  messages 
of  up  to  64  characters  of  telemetry  and  messages 
from  the  bus  for  transmission  within  the  beacon 
broadcasts,  which  shall  contain  the  "TINYSCOPE" 
character  string  in  its  packet. 

Command  and  Data  Handling  Subsystem 
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TR-60  The  Spacecraft  shall  be  capable  of  monitoring 
the  health  and  safety  of  the  spacecraft  and  payload. 

TR-61  The  Spacecraft  shall  report  in  spacecraft 
telemetry  log  the  health  and  safety  of  the 
spacecraft  and  payload. 

TR-62  The  Spacecraft  onboard  processor  shall  be 
capable  of  being  reset  via  a  ground  command. 

TR-63  The  Spacecraft  shall  convert  analog  sensor  data 
to  digital  format. 

TR-64  The  Spacecraft  shall  transmit  real-time 
telemetry  data  to  the  ground  when  in  contact  with  a 
ground  station. 

TR-65  The  Spacecraft  shall  record  all  telemetry  data. 

TR-66  The  Spacecraft  shall  be  capable  of  concurrent 
transmission  and  storage  of  real-time  telemetry. 

TR-67  The  Spacecraft  shall  report  command  acceptance 
or  rejection  in  telemetry  log  upon  receipt. 

TR-68  The  Spacecraft  shall  report  command  execution 
in  telemetry  log. 

TR-69  The  Spacecraft  shall  be  capable  of  playing  back 
stored  telemetry  data  while  in  any  mode. 

TR-70  The  Spacecraft  shall  be  capable  of  decrypting 
command  and  data  uploads  using  civil  decryption 
coding . 

TR-71  The  Spacecraft  shall  be  capable  of  source 
authentication  of  all  received  commands. 

TR-72  The  Spacecraft  shall  execute  only  commands  that 
are  source  authenticated. 

TR-73  The  Spacecraft  shall  have  a  command 
authentication  bypass. 

TR-74  The  Spacecraft  command  authentication  bypass 
shall  be  accomplished  by  means  of  a  fixed  length 
timer . 
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TR-75  The  Spacecraft  shall  autonomously  reset  the 
authentication  bypass  timer  upon  receipt  of  a 
successfully  authenticated  command. 

TR-76The  Spacecraft  shall  reject  invalid  commands. 

TR-77  The  Spacecraft  shall  identify  rejected  commands 
in  telemetry  log(s) . 

TR-78  The  Spacecraft  shall  validate,  process,  and 
execute  flight  software  update  commands,  ephemeris 
table  data,  and  star  database  loads. 

TR-79The  Spacecraft  shall  be  capable  of  receiving 
command  loads  across  multiple  contacts. 

TR-80  The  Spacecraft  shall  be  capable  of  receiving 
flight  software  updates  across  multiple  contacts. 

TR-81  The  Spacecraft  shall  use  unique  commands  to 
change  state  and  condition. 

TR-82  The  Spacecraft  shall  record  all  mission  data. 

TR-83  The  Spacecraft  shall  be  capable  of  resending 
stored  mission  data  multiple  times. 

TR-84  The  Spacecraft  shall  retain  all  stored  data 
when  transitioning  into  and  out  of  any  operational 
mode . 

TR-85  The  Spacecraft  shall  acquire  ephemeris  and 
ancillary  data  from  the  spacecraft  that  is  necessary 
to  meet  instrument  imaging  requirements. 

TR-86  The  Spacecraft  shall  use  a  file  based  data 
management  scheme  for  stored  data. 

TR-87  The  Spacecraft  shall  provide  a  listing  or 
directory  of  its  file  system  including  file 
attributes  on  command. 

TR-88  The  Spacecraft  shall  maintain  mass  storage  file 
attributes  that  include  at  a  minimum: 


A  file  name 
A  unique  time  stamp 
The  file  length 
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•  Flags  that  provide  data  protection  status  (over¬ 
write  or  not) 

•  Flag  that  indicates  whether  the  file  has  been 
transmitted 

TR-89The  Spacecraft  shall  uniquely  identify  each 
data  file  in  mass  storage  using  a  root  name 
associated  with  the  ground  location  of  the  data 
content . 

TR-90  The  Spacecraft  shall  designate  any  single  or 
set  of  mission  data  files  as  protected  on  command. 

TR-91  The  Spacecraft  shall  autonomously  mark  mission 
data  files  in  mass  storage  as  non-protected  after 
acknowledgement  of  receipt  by  the  ground  station. 

TR-92  The  Spacecraft  shall  designate  any  single  or 
set  of  mission  data  files  as  non-protected  on 
command . 

TR-93  The  Spacecraft  shall  only  overwrite  non¬ 
protected  mission  data. 

TR-94  The  Spacecraft  shall  overwrite  mission  data 
starting  from  oldest  to  youngest. 

TR-95  The  Spacecraft  shall  be  capable  of  repeat 
playbacks  of  stored  data. 

TR-96  The  Spacecraft  shall  autonomously  determine 
which  mass  storage  files  will  be  down-  linked  at  the 
next  ground  contact  opportunity. 

TR-97  The  Spacecraft  shall  downlink  mass  storage 
files  in  a  non-standard  order  upon  command  from  the 
ground . 

TR-98  The  Spacecraft  shall  retransmit  individual 
files  on  command. 

TR-99  The  Spacecraft  shall  be  capable  of  diagnosing 
mass  storage  problems. 

TR-100  The  Spacecraft  shall  have  autonomous  internal 
fault  detection  and  responses  for  each  subsystem. 

TR-101  The  Spacecraft  shall  record  in  telemetry  log 
that  faults  responses  have  been  completed. 
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Thermal  Control 

TR-102  The  Spacecraft  shall  be  thermally  safe  for 
continuous  operations  in  all  operational  modes. 

TR-103  The  Spacecraft  shall  have  a  thermal  control 
system  that  monitors  and  reports  in  the  telemetry 
log  the  temperatures  of  subsystems  on  the 
Spacecraft . 

Structural  and  Mechanical 

TR-104  The  Spacecraft  structure  shall  provide  a 
structural  mounting  interface  with  a  nadir  field-of- 
view  clear  of  obstructions  for  the  payload. 

TR-105  The  Spacecraft  structure  shall  include  a 
structural  mounting  interface  that  is  isolated  from 
mechanical  and  thermal  disturbances  from  the 
Spacecraft 

TR-106  The  Spacecraft  shall  be  designed  to  permit 
full  range  deployment  of  mechanisms  after 
integration  with  the  Spacecraft  during  ground 
processing . 

Flight  Software 

TR-107  The  Spacecraft  flight  software  shall  be 
reprogrammable  on  orbit. 

TR-108  The  Spacecraft  shall  monitor  software  tasks  to 
detect  for  infinite  loops  or  stalled  processes. 

TR-109  The  Spacecraft  flight  software  shall  detect 
and  correct  single  bit  memory  errors. 

TR-110  The  Spacecraft  stored  commands  shall  be 
unaffected  by  a  flight  software  upload. 

TR-111  The  Spacecraft  flight  software  shall  store  the 
version  identifier  of  reprogrammable  software 
onboard . 

TR-112  The  Spacecraft  shall  preserve  contents  of  the 
telemetry  log  after  rebooting  or  power  cycling. 

TR-113  The  Spacecraft  shall  initialize  flight 
software  and  begin  operations  without  the  need  of  a 
ground  based  command. 
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TR-114  The  Spacecraft  processor  shall  execute  a 
restart  of  its  software  in  response  to  a  ground 
command . 

TR-115  The  Spacecraft  flight  software  shall  provide  a 
capability  to  store  and  execute  absolute-time 
command  sequences . 

TR-116The  Spacecraft  flight  software  shall  provide  a 
capability  to  store  and  execute  relative-time 
command  sequences. 

TR-117  The  Spacecraft  flight  software  shall  execute 
real-time  commands  before  executing  stored  commands. 

TR-118  The  Spacecraft  flight  software  shall  provide 
the  capability  to  store  multiple  time-tagged  command 
sequences . 

TR-119  The  Spacecraft  flight  software  stored  command 
sequences  shall  be  modifiable  by  ground  command. 

TR-120  The  Spacecraft  flight  software  command 
sequences  shall  be  enabled,  disabled  or  canceled  by 
ground  command. 

TR-121  The  Spacecraft  flight  software  shall  be 
capable  of  placing  the  contents  of  the  stored 
command  buffer  into  the  telemetry  log. 

TR-122  The  Spacecraft  flight  software  shall  uniquely 
identify  stored  command  sequences. 

TR-123  The  Spacecraft  flight  software  shall  use  the 
unique  command  sequence  identifier  to  report  the 
status  of  each  actively  executing  command  sequence 
in  telemetry. 

4.1.2  Performance  Requirements 

4. 2. 1.1  TINYSCOPE  Payload  Subsystem 

TR-124  The  payload  shall  have  a  minimum  field  of  view 
that  provides  a  25  square  kilometer  swath  when  nadir 
pointing . 

TR-125  Data  compression  algorithms  applied  to  image 
data  shall  be  lossless. 
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TR-126  Non-uniformity  correction  algorithms  shall  be 
fully  reversible  and  coefficients  shall  be 
transmitted  with  each  image  file. 

TR-127  The  payload  shall  provide  a  pixel-to-pixel 
increment,  in  both  the  along  track  and  cross  track 
directions,  equivalent  to  a  Ground  Sampling  Distance 
(GSD)  less  than  or  equal  to  4  meters  for  a 
panchromatic  band. 

TR-128  Payload  data  shall  be  quantized  to  a  minimum 
of  8  bits . 

TR-129The  payload  structure  shall  be  of  sufficient 
strength  and  stiffness  to  maintain  structural 
integrity  during  ground  testing  and  transportation 
and  launch. 

TR-130  The  payload  structure  shall  provide  a  mounting 
interface  to  the  spacecraft  bus. 

TR-131  The  payload  structure  shall  include  a 
mechanical  alignment  device  to  co-align  the  optical 
path  to  the  spacecraft  bus  structure  and  inertial 
reference  frame. 

TR-132  The  payload  mechanical  alignment  device  shall 
be  internally  stable  through  the  full  range  of 
design  temperatures. 

TR-133  The  payload  shall  be  thermally  stable  while  in 
operational  modes. 

TR-134  The  payload  shall  be  designed  to  operate  from 
a  5V  direct  current  power  subsystem. 

TR-135  The  payload  shall  have  an  average  power 
consumption  that  does  not  exceed  8  Watts. 

TR-136  The  payload  shall  have  a  peak  power 
consumption  that  does  not  exceed  10  Watts. 

TR-137  The  payload  software  shall  be  reprogrammable 
on  orbit. 

TR-138  The  payload  processor  shall  be  capable  of 
being  reset  on  orbit. 

TR-139  The  payload  processor  shall  continuously 
monitor  its  health  and  safety. 
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TR-140  The  payload  shall  time  tag  image  data  with 
accuracy  of  1  millisecond  relative  to  the  spacecraft 
time  reference. 

TR-141  The  payload  software  shall  provide  sufficient 
telemetry  to  ensure  proper  control  and  monitoring  of 
health  and  safety  and  to  identify  anomalous 
conditions . 

TR-142  The  payload  shall  be  designed  to  operate  and 
meet  all  design  requirements  for  six  months 
following  commissioning  on  orbit. 

TR-143  The  payload  shall  be  capable  of  being  placed 
in  a  state  of  storage  without  requiring  maintenance 
for  a  period  of  six  months. 

4. 2. 1.2  TINYSCOPE  Bus  Subsystem 

TR-144  The  spacecraft  shall  be  capable  of  operating 
safely  without  any  ground  intervention  for  a  period 
of  72  hours. 

Electrical  Power  Subsystem 


TR-145  The  spacecraft  shall  provide  continuous  and 
peak  power  with  a  20%  margin  for  all  phases  of 
mission  operation. 

Attitude  Control  and  Determination  Subsystem 

TR-146  The  Spacecraft  shall  perform  maneuvers  to  any 
inertial  attitude  meeting  pointing  requirements  and 
stabilize  within  90  seconds. 

TR-147  The  spacecraft  shall  have  absolute  pointing 
accuracy  of  less  than  or  equal  to  0.1  degrees. 

TR-148  The  Spacecraft  shall  compute  orbital  position 
accurate  to  30  m  radial,  30  m  in-track,  and  30  m 
cross-track . 

TR-149The  Spacecraft  shall  provide  orbital  velocity 
accurate  to  0.30  m/sec  radial,  0.30  m/sec  in-track, 
and  0.30  m/sec  cross  track. 

TR-150  The  Spacecraft  shall  be  capable  of  propagating 
the  on-board  state  for  at  least  24  hours. 
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TR-151  The  spacecraft  shall  support  imaging 
operations  for  up  to  24-hours  from  an  onboard 
propagated  ephemeris. 

Communications  Subsystem 

TR-152  Radio  frequency  link  margins  shall  be  at  least 
+3dB  in  all  operational  modes. 

TR-153  The  spacecraft  shall  transmit  a  minimum  of  90% 
of  real-time  and  recorded  telemetry  to  the  ground 
segment . 

TR-154  The  primary  communications  system  shall  have  a 
bit  error  rate  (BER)  at  operational  data  rates  of 
less  than  or  equal  to  IE-6  after  demodulation  and 
error  correction. 

TR-155  The  primary  command  uplink  shall  be  at  16 
Kbps . 

TR-15  6  The  primary  downlink  shall  at  a  minimum  be  1.2 
Mbps . 

TR-157  The  backup  command  uplink  shall  be  at  a 
minimum  250  bps  to  the  beacon  system. 

TR-158  The  backup  downlink  through  the  beacon  system 
shall  be  at  a  minimum  200  bps. 

TR-159  The  beacon  system  shall  have  minimum  broadcast 
repetition  rates  on  the  order  of  5-60  seconds. 

TR-160  The  beacon  system  shall  have  a  bit  error  rate 
(BER)  at  operational  data  rates  of  less  than  or 
equal  to  IE-5  after  demodulation  and  error 
correction . 

Command  and  Data  Handling  Subsystem 

TR-161  The  Spacecraft  shall  be  capable  of  storing  at 
least  72  hours  of  Spacecraft  telemetry  data  at  the 
maximum  onboard  telemetry  rate. 

TR-162  The  Spacecraft  shall  be  capable  of  storing  at 
least  72  uncompressed  images  and  associated 
ephemeris  and  ancillary  data. 
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TR-163  The  Spacecraft  shall  time  tag  ephemeris  and 
ancillary  data  to  the  spacecraft  time  reference  with 
an  accuracy  of  1  millisecond. 

TR-164  The  Spacecraft  shall  time-tag  telemetry  data 
to  the  spacecraft  time  reference  with  an  accuracy  of 
1  millisecond. 

Structural  and  Mechanical 

TR-165The  Spacecraft  structure  shall  be  sufficiently 
stiff  to  meet  the  axial  and  lateral  frequency 
requirements  as  defined  in  GSFC-STD-7000 . 

TR-166  The  Spacecraft  structure  shall  be  of 
sufficient  strength  and  stiffness  to  maintain 
structural  integrity  and  withstand  all  launch  and 
launch  vehicle  separation  environments  as  defined  in 
GSFC-STD-7000 . 

TR-167  The  Spacecraft  structure  shall  be  of 
sufficient  strength  and  stiffness  to  maintain 
structural  integrity  and  withstand  all  ground 
testing,  handling,  transportation,  and  mission  on- 
orbit  environments  as  defined  in  GSFC-STD-7000. 

Flight  Software 

TR-168  The  Spacecraft  flight  software  stored  command 
capability  shall  store  up  to  72  hours  of  spacecraft 
command  sequences. 

TR-169  The  Spacecraft  flight  software  shall  be 
capable  of  executing  commands  with  an  accuracy  of 
100  milliseconds  or  less. 

4.1.2  Physical  Characteristics 

TR-170  The  TINYSCOPE  system  mass  shall  consist  of  the 
TINYSCOPE  satellite  bus  and  the  payload  subsystem 
with  a  launch  mass  of  14  kg  or  less. 

TR-171 TINYSCOPE  shall  conform  to  all  applicable 
standards  for  the  Nanosatellite  Launch  Adapter 
System. 

4.1.3  Environmental  Requirements 

TR-172  All  subsystems  shall  be  qualified  at 
acceptance  levels  for  Thermal  Cycle,  Thermal  Vacuum 
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Cycle,  Vibration,  and  Shock  Testing  as  defined  in 
GSFC-STD-7000 . 


TR-173  The  satellite  bus  and  payload  electronics 
shall  be  capable  of  correcting  for  single  event 
memory  corruption  caused  by  radiation. 

TR-174  The  TINYSCOPE  spacecraft  and  payload  shall  be 
capable  of  operation  in  low  Earth  orbit  (LEO) 
without  unrecoverable  failure  due  to  radiation 
effects . 


4.3  Communications  Ground  Station  (GS) 


4.3.1  Functional  Performance 

TR-175  The  GS  shall  provide  the  capability  to  measure 
beacon  signal  strength. 

TR-176The  GS  shall  provide  the  capability  to 
autonomously  steer  the  antenna  in  azimuth  and 
elevation  to  track  the  beacon  signal. 

TR-177  The  GS  shall  provide  the  capability  to 
manually  steer  the  antenna  in  azimuth  and  elevation 
to  track  the  beacon  signal. 

TR-178  The  GS  shall  have  the  capability  to  receive 
transmissions  from  the  satellite  primary 
communications  system. 


TR-179The  GS  shall  have  the  capability  to  encode  and 
decode  beacon  and  primary  signals. 

TR-180  The  GS  shall  have  the  capability  to  receive 
commands  and  scripts  from  the  MOC . 


TR-181  The  GS  shall  have  the  capability  to  transfer 
data  to  the  MOC . 

TR-182  The  GS  shall  have  the  ability  to  be  controlled 
from  the  MOC. 


TR-183  The  GS  shall  have  the  capability  to  encrypt 
and  decrypt  communications . 

TR-184  The  GS  shall  have  the  capability  to  propagate 
satellite  orbits. 


TR-185  The  GS  antenna  shall  have  the  capability  to 
scan . 
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TR-186  The  GS  shall  have  the  capability  to  transmit 
and  receive  simultaneously. 

4 . 4  Mission  Operations  Center  (MOC) 

4.4.1  General 

TR-187  The  MOC  shall  use  Universal  Time  Coordinated 
(UTC)  time  as  the  time  base  for  all  operations 
activities . 

TR-188  The  MOC  shall  receive  all  data  for  the  life  of 
the  mission. 

TR-189  The  MOC  shall  support  end  of  life 
decommissioning  activities. 

TR-190  The  MOC  shall  support  a  single  8-hour  by  5-day 
shift  (M-F)  approach  and  operate  autonomously 
whenever  not  staffed. 

TR-191  All  functional  applications  in  the  MOC  shall 
have  the  ability  to  run  unattended  while  performing 
all  routine  and  periodic  operations  for  72  hours. 

TR-192The  MOC  shall  autonomously  monitor  the  event 
log  and  notify  appropriate  on-call  personnel  when 
the  MOC  is  not  staffed. 

TR-193  The  MOC  shall  generate  commands  for 
transmission  to  the  spacecraft. 

TR-194  The  MOC  shall  accept  telemetry  and  mission 
data  from  the  spacecraft. 

TR-195  The  MOC  shall  send  spacecraft  commands  to  the 
ground  station  for  S-band  uplink. 

TR-196  The  MOC  shall  receive  real-time  telemetry  from 
the  ground  station. 

TR-197  The  MOC  shall  receive  stored  telemetry  logs 
from  the  ground  station. 

4.4.2  Activity  Planning  Element  (APE) 

TR-198  The  APE  shall  provide  the  capability  to  plan 
and  schedule  all  spacecraft  collection  and 
maintenance  activities  for  the  life  of  the  mission. 
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TR-199  The  APE  shall  produce  time-ordered  activity 
plans  listing  all  planned  activities  for  the 
spacecraft  planning  window. 

TR-200  The  APE  shall  incorporate  all  resource  down 
times  or  reserved  times  into  schedule  generation 
events . 

TR-201  The  APE  shall  convert  collection  and 
maintenance  requests  into  spacecraft  activities . 

TR-202  The  APE  shall  provide  the  capability  to  create 
and  modify  activity  priorities,  constraints,  and 
rules . 

TR-203  The  APE  shall  automatically  check  for  activity 
constraint  and  rule  violations  during  schedule 
generation . 

TR-204  The  APE  shall  automatically  check  for  resource 
constraint  and  rule  violations  during  schedule 
generation . 

TR-205  The  APE  shall  provide  the  capability  to 
automatically  schedule  all  spacecraft  and  ground 
station  activities  within  operational  resource 
constraints . 

TR-206  The  APE  shall  provide  the  capability  to 
produce  a  Coordinated  Universal  Time  (UTC)  time- 
based  activity  schedule  in  terms  of  specific 
start/stop  times. 

TR-207  The  APE  shall  provide  the  capability  to 
generate  a  conflict-free  activity  schedule  spanning 
72-hours  of  activity. 

TR-208  The  APE  shall  provide  the  capability  to 
generate  a  graphical  timeline  of  activity  plans  and 
schedules . 

TR-209  The  APE  shall  provide  a  display  of  planned, 
currently  active  and  past  observatory  and  ground 
activities . 

TR-210  The  APE  shall  produce  and  deliver  activity 
schedules  to  the  data  management  element. 
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TR-211  The  APE  shall  be  capable  of  archiving  and 
recovering  all  planning  and  scheduling  data  for  the 
life  of  the  mission. 

4.4.3  Flight  Operations  Element  (FOE) 

TR-212  The  FOE  shall  interface  with  the  ground 
communications  network  for  the  exchange  of  mission 
data  and  products  among  the  ground  system  elements . 

TR-213  The  FOE  shall  provide  an  interface  between  the 
ground  system  elements  and  the  space-ground 
communications  links. 

TR-214  The  FOE  shall  provide  an  anomaly  reporting  and 
status  tracking  capability. 

TR-215  The  FOE  shall  ensure  that  no  single  point  of 
failure  exists  for  critical  command  and  control 
functions . 

TR-216  The  FOE  shall  provide  the  capability  to 
support  training,  testing,  or  system  maintenance 
with  no  interruption  to  FOE  functionality. 

TR-217  The  FOE  shall  provide  the  capability  to  log, 
track,  and  report  system  faults  and  failures. 

TR-218  The  FOE  shall  be  capable  of  generating 
commands  to  perform  the  spacecraft  functions . 

TR-219  The  FOE  shall  be  capable  of  generating 
commands  to  support  the  retransmission  of  telemetry 
data . 

TR-220  The  FOE  shall  perform  command  encryption  and 
authentication . 

The  FOE  shall  assign  levels  of  command  authority  to 
ensure  that  only  authorized  personnel  can  perform 
designated  command  functions. 

TR-221 Command  authority  shall  be  controlled  by  login 
attributes . 

TR-222  The  FOE  shall  provide  the  capability  to  allow 
authorized  operators  to  transmit  commands  to  the 
observatory . 
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TR-223  The  FOE  shall  prevent  simultaneous  sending  of 
commands  by  multiple  operators . 

TR-224  The  FOE  shall  provide  the  capability  to 
perform  real  time  commanding  to  the  observatory. 

TR-225  The  FOE  shall  perform  verification  of  real¬ 
time  commands  to  the  observatory. 

TR-226  The  FOE  shall  provide  the  capability  to 
generate,  uplink,  and  verify  discrete  observatory 
commands . 

TR-227  The  FOE  shall  provide  the  capability  to 
generate  command  sequences  via  a  scripting  language. 

TR-228  The  FOE  shall  provide  the  capability  to  uplink 
command  scripts  or  software  updates  that  are  stored 
as  named  files. 

TR-229  The  FOE  shall  produce  a  load  generation  report 
for  all  loads,  containing  accounting  information, 
description  of  load  contents,  any  warning  and/or 
error  messages  and  a  summary  of  creation  results. 

TR-230  The  FOE  shall  be  capable  of  performing 
automatic  constraint  and  rule  checking  of  discrete 
commands  and  command  loads. 

TR-231  The  FOE  shall  require  at  least  one  additional 
operator  confirmation  prior  to  the  transmission  of 
commands  or  command  sequences  that  have  failed 
constraint  check. 

TR-232  The  FOE  shall  be  capable  of  notifying  the 
operator  that  the  commands  sent  to  the  spacecraft 
were  correctly  received. 

TR-233  The  FOE  shall  provide  the  capability  to 
manually  retransmit  commands  or  command  loads  that 
were  not  accepted  by  the  spacecraft. 

TR-234  The  FOE  shall  define  spacecraft  commands  and 
their  characteristics  in  a  command  database. 

TR-235  The  FOE  shall  have  the  capability  to  search 
and  sort  spacecraft  commands  defined  in  the  command 
database . 
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TR-236  The  FOE  shall  archive  all  command  operations 
and  command  history  for  the  life  of  the  mission. 

TR-237  The  FOE  shall  provide  the  capability  to  time 
tag  all  spacecraft  and  ground  system  data  with  a  UTC 
time . 

TR-238  The  FOE  shall  provide  the  capability  to  replay 
telemetry  by  ground  receipt  time  or  spacecraft  time. 

TR-239  The  FOE  shall  provide  the  capability  to 
display  operator-selected  telemetry  data  in  real 
time . 

TR-240  The  FOE  shall  provide  a  capability  to  verify 
in  real-time  that  telemetry  parameters  are  within 
prescribed  operating  limits. 

TR-241  The  FOE  shall  define  spacecraft  telemetry  and 
their  characteristics  in  a  telemetry  database. 

TR-242  The  FOE  shall  have  the  capability  to  search 
and  sort  spacecraft  telemetry  defined  in  the 
telemetry  database. 

TR-2  4  3  The  FOE  shall  be  capable  of  ingesting  and 
storing  all  telemetry  data  for  trending  and 
analysis . 

TR-244  The  FOE  shall  examine  spacecraft  data  to 
determine  if  any  unexpected  deviations  from  the  pre¬ 
planned  timeline  have  occurred. 

TR-245  The  FOE  shall  produce  an  as-flown  timeline 
that  reflects  the  activities  that  were  actually 
executed  by  the  spacecraft. 

TR-246  The  FOE  shall  create  pass  summaries  that 
describe  the  results  of  each  spacecraft  contact. 

TR-247  The  FOE  shall  perform  evaluation  of  on-board 
derived  ephemeris  and  attitude  estimates  available 
in  the  telemetry  log. 

TR-248  The  FOE  shall  provide  the  capability  to 
automatically  detect  when  the  spacecraft  orbital 
parameters  deviate  from  established  limits. 
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TR-249  The  FOE  shall  have  the  capability  to  perform 
real-time  attitude  estimation  using  raw  sensor  data 
in  the  telemetry  data. 

TR-250  The  FOE  shall  provide  the  capability  to 
generate  the  definitive  ephemeris  of  the  observatory 
at  an  accuracy  of  30m  in  each  axis. 

TR-251  The  FOE  shall  provide  the  capability  to 
propagate  the  observatory  orbit  for  72  hours. 

TR-252  The  FOE  shall  produce  data  necessary  to 
support  Conjunction  Assessment  activities. 

TR-253  The  FOE  shall  receive  data  necessary  to 
support  Conjunction  Assessment  activities. 

TR-254  The  FOE  shall  propagate  object  ephemeris  and 
compare  results  to  predicted  observatory  ephemeris. 

TR-255  The  FOE  shall  have  the  capability  to  generate 
attitude  estimates  of  accuracy  meeting  mission 
requirements  from  raw  sensor  data  contained  in 
telemetry  logs . 

TR-256  The  FOE  shall  be  capable  of  validating  the  on¬ 
board  attitude  estimates  meet  mission  accuracy 
requirements . 

TR-257  The  FOE  shall  predict  star  tracker  target 
fields  and  compare  these  predicts  to  star 
acquisition  data  available  in  telemetry  logs  on  an 
as-needed  basis. 

TR-258  The  FOE  shall  accept  a  star  catalog  from  an 
external  source  and  have  the  ability  to  maintain  and 
uplink  the  star  catalog. 

TR-259  The  FOE  shall  be  capable  of  generating 
maneuver  plans  in  support  of  all  observatory 
attitude  maintenance  and  collection  activities. 

TR-260  The  FOE  shall  monitor  on-board  sensor 
calibrations  and  re-calibrate,  as  necessary  to  meet 
absolute  attitude  accuracy  requirements. 

TR-261  The  FOE  shall  specify  and  generate  attitude 
sensor  calibration  maneuver  sequences  to  provide 
sufficient  sensor  data  to  derive  sensor  alignment  & 
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calibration  coefficients  meeting  mission  attitude 
determination  requirements. 

TR-262  The  FOE  shall  provide  a  capability  to  display 
the  spacecraft  orbit  and  ground  tracks. 

TR-263  The  FOE  shall  be  capable  of  ingesting 
externally-generated  spacecraft  ephemeris  data. 

TR-264  The  FOE  shall  provide  the  capability  to  modify 
any  re-programmable/writeable  memory  locations  on 
the  observatory. 

TR-2  65  The  FOE  shall  have  the  capability  to  command 
data  in  mass  storage  to  be  unprotected. 

TR-266The  FOE  shall  provide  a  capability  for 
operators  to  select  data  in  mass  storage  for 
downlink . 

TR-267  The  FOE  shall  time  tag  all  event  messages  with 
a  UTC  time. 

TR-268  The  FOE  shall  provide  the  capability  to  log 
all  event  messages  for  the  life  of  the  mission. 

TR-269  The  FOE  shall  provide  the  capability  to 
display  any  event  messages  and  logs. 

TR-270  The  FOE  shall  be  capable  of  autonomously 
establishing  a  command  and  telemetry  link  with  the 
ground  station  for  every  spacecraft  contact. 

4.4.4  Data  Management  Element  (DME) 

TR-271  The  DME  shall  provide  the  capability  to 
archive  and  retrieve  engineering  data  products . 

TR-272  The  DME  shall  provide  the  capability  to 
archive  and  retrieve  telemetry  data  products . 

TR-273  The  DME  shall  provide  the  capability  to 
archive  and  retrieve  mission  data  products. 

TR-274  The  DME  shall  archive  all  mission  data  in  raw 
and  processed  forms. 

TR-275  The  DME  shall  archive  raw  mission  data  in  a 
separate  archive  from  processed  data. 
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TR-276The  DME  shall  provide  the  capability  to 
authorize  and  limit  access  to  archival  databases. 

TR-277  The  DME  shall  provide  the  capability  to 
distribute  raw  and  processed  mission  data  to  users. 

TR-278  The  DME  shall  provide  the  capability  to 
provide,  at  a  minimum,  the  following  basic  services: 

•  Image  georeferencing 

•  Orthorectification 

•  Correct  radiometric  distortion  caused  by 
instrumentation  error 


5  MISSION  OPERATIONS  REQUIREMENTS 

TR-279The  spacecraft  shall  be  powered  off  following 
integration  and  throughout  launch  operations. 

TR-280  The  TINYSCOPE  satellite  mission  operations 
shall  begin  no  later  than  24  hours  prior  to  launch. 

TR-281  The  TINYSCOPE  System  shall  be  capable  of 
operations  from  the  NPS  Mission  Operations  Center. 

TR-282  The  spacecraft  shall  be  designed  to  operate 
and  meet  all  design  requirements  for  six  months 
following  commissioning  on  orbit. 

TR-283  The  spacecraft  shall  be  capable  of  being 
placed  in  a  state  of  storage  without  requiring 
maintenance  for  a  period  of  six  months. 

TR-284  The  spacecraft  shall  be  designed  for  an 
overall  probability  of  success  of  80%  at  the  end  of 
its  design  life. 

TR-285  The  spacecraft  shall  be  compliant  with  NASA 
requirements  for  limiting  orbital  debris. 

TR-286  The  spacecraft  shall  be  designed  to  operate  in 
a  sun-synchronous  circular  orbit  at  an  altitude  of 
500  kilometers  +-  120  kilometers. 

TR-287  The  spacecraft  shall  have  three  operational 
modes  as  follows: 

•  NORMAL  Mode  is  the  nominal  operational  mode  for 
the  spacecraft. 
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•  SAFE  Mode  provides  maximum  sun  exposure  to  the 
solar  array  and  a  spacecraft  configuration  that 
does  not  allow  image  collection.  The  payload  and 
S-band  radio  are  deactivated  and  the  beacon 
system  transmits  continuous  telemetry  data 
through  the  omni-directional  antenna. 

•  EMERGENCY  Mode  deactivates  all  subsystems  with 
the  exception  of  the  beacon  system.  The  beacon 
transmits  a  periodic  distress  signal  along  with 
telemetry  data  to  preserve  power.  The  EPS 
provides  a  direct  path  from  the  solar  array  to 
the  battery  for  charging.  The  spacecraft  is  not 
capable  of  image  collection,  high  rate 
communication,  or  attitude  control  in  EMERGENCY 
Mode . 


6  VERIFICATION  REQUIREMENTS 

6 . 1  Structural  and  Mechanical  Verification  Requirements 

TR-288  Random  vibration  tests  shall  be  conducted  on 
the  integrated  spacecraft  bus,  payload  system,  and 
the  final  spacecraft  assembly. 

TR-289  Random  vibration  tests  shall  cover  frequency 
ranges  from  20  to  2000  Hz. 

TR-290  Random  vibration  test  items  shall  be  subjected 
to  random  vibration  along  each  axis  for  one  minute 
each . 

TR-291  Random  vibration  test  qualification  and 
acceptance  test  levels  will  be  determined  in 
accordance  with  GSFC-STD-7000 . 

TR-292  The  mass  properties  of  the  integrated 
spacecraft  shall  be  determined  by  measurement. 

TR-293  The  following  mass  properties  shall  be 
determined : 

•  Weight 

•  Center  of  gravity 

•  Moment  of  inertia 

•  Balance 
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TR-294  Subsystem  qualification  tests  shall  be 
performed  for  each  mechanical  operation. 

TR-295  The  integrated  spacecraft  shall  be  tested  to 
demonstrate  that  each  mechanical  device  is  installed 
correctly  and  that  there  are  no  interference 
problems  that  will  adversely  affect  the  mission. 

6 . 2  Electromagnetic  Compatibility  Verification 
Requirements 

TR-296  Radiated  emission  tests  shall  be  performed  on 
spacecraft  transmitters  to  identify  electro-magnetic 
interference . 

TR-297  The  integrated  spacecraft  shall  be  tested  for 
stray  magnetic  fields  which  may  affect  the  on-board 
magnetometers . 

6 . 3  Electrical  Function  Verification  Requirements 

TR-298  Electrical  interface  tests  shall  be  performed 
on  each  component  and  subsystem  prior  to  integration 
to  verify  that  interface  signals  follow  the  correct 
signal  path  and  are  within  acceptable  limits. 

TR-299  Electrical  harnesses  shall  be  tested  to  verify 
proper  routing,  impedance,  isolation,  and 
workmanship  prior  to  integration. 

TR-300  An  aliveness  test  shall  be  performed  prior  to 
and  following  integration  to  verify  that  the 
component  or  subsystem  is  functioning. 

TR-301 A  comprehensive  performance  test  (CPT)  shall 
be  conducted  on  each  component  and  subsystem 
following  environmental  testing  to  demonstrate  that 
components  meet  performance  requirements  within 
allowable  tolerances. 

TR-302  CPT  shall  be  conducted  at  the  hot  and  cold 
extremes  of  the  thermal-vacuum  test  for  both  maximum 
and  minimum  input  voltage. 

6 . 4  Vacuum  and  Thermal  Verification  Requirements 

TR-303  All  components  and  subsystem  assemblies  shall 
be  subjected  to  thermal-vacuum  tests  that 
demonstrate  function  at  temperatures  ten  degrees 
higher  and  lower  than  expected  flight  temperatures. 
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TR-304  The  integrated  spacecraft  shall  be  subjected 
to  thermal-vacuum  tests  that  demonstrate  function  at 
temperatures  five  degrees  higher  and  lower  than 
expected  flight  temperatures. 

TR-305  Thermal-vacuum  tests  shall,  at  a  minimum, 
subject  hardware  to  four  complete  thermal  cycles. 

TR-306  Thermal-vacuum  tests  shall  incorporate  a 
period  for  out-gassing. 

TR-307  CPT  shall  be  performed  at  each  hot  and  cold 
soak  plateau  of  a  thermal  cycle. 

6 . 5  Optical  Calibration  Requirements 

TR-308  Spatial  edge  response  shall  be  characterized 
based  on  measurements  at  the  integrated  payload 
level,  before  and  after  vibration  testing  and  across 
the  entire  field  of  view  in  all  bands. 

TR-309A  stray  light  model  shall  be  developed  that 
includes  the  entire  optical  system  including 
baffles,  detectors  and  portions  of  the  satellite  bus 
that  may  reflect  light  into  the  sensor. 

TR-310  The  radiometric  response  of  detectors  shall  be 
characterized  across  the  expected  operating 
temperature  range  of  the  payload. 

TR-311  The  payload  shall  be  characterized  to  ensure 
that  it  will  meet  absolute  radiometric  accuracy, 
pixel-to-pixel  uniformity  and  radiometric  stability 
in  expected  orbital  conditions . 

TR-312  The  signal  to  noise  ratio  of  all  detectors 
shall  be  characterized. 

TR-313  The  baseline  1/f  noise  parameters  for  all 
imaging  detectors  shall  be  characterized. 

TR-314  The  coherent  noise  of  the  integrated  payload 
shall  be  characterized. 

TR-315  The  dark  level  coherent  noise  of  the 
integrated  payload  shall  be  characterized. 

TR-316  Dead,  inoperable,  and  out-of-spec  detectors 
shall  be  identified  and  recorded. 
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TR-317  Alignment  of  the  telescope  optical  axis 
relative  to  the  spacecraft  shall  be  measured. 

TR-318  Degradation  of  image  quality  due  to  internal 
spacecraft  vibration  shall  be  characterized. 

TR-319  Degradation  of  image  quality  due  to  spacecraft 
motion  shall  be  characterized. 

TR-320  Alignment  and  focus  changes  to  the  optical 
path  due  to  thermal  expansion  or  contraction  shall 
be  characterized. 

TR-321  Aberrational  variations  from  design  to 
production  shall  be  measured  and  characterized. 

TR-322  Variations  in  detector  response  shall  be 
characterized  through  two  out-gassing  cycles. 
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APPENDIX  C - CONT AMINAT I ON  CONTROL  PLAN 


This  document  is  a  part  of  the  TINYSCOPE  Project 
Documentation,  controlled  by  the  TINYSCOPE  Project  Manager 
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Laboratory  at  the  Naval  Postgraduate  School,  Monterey,  CA. 
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1  PURPOSE 

This  contamination  control  plan  describes  the  requirements 
and  procedures  for  the  environmental  management  of  the 
TINYSCOPE  spacecraft.  This  plan  is  applicable  during  all 
phases  of  development  to  include  fabrication,  assembly, 
integration  and  test,  and  transportation  and  storage. 


2  SPACECRAFT  CONTAMINATION  SOURCES 

Contamination  of  a  spacecraft  may  occur  at  anytime  from  the 
beginning  of  individual  component  fabrication  through 
launch  and  into  the  spacecraft's  service  life.  Table  1 
below  lists  the  spacecraft's  development  cycle  and  the 
contamination  sources  that  must  be  guarded  against  in  each 
phase . 

Table  1.  Contamination  Sources  for  Spacecraft.  Taken 
from  (Contamination  Control  Plan  for  Midshipman  Space 
Technology  Applications  Research  MidSTAR) -1  Spacecraft,  22 
June  2004 . ) 


Development 

Phase 

Molecular 

Particulate 

Fabrication 

materials  out-gassing, 
machining  oils, 
fingerprints,  air 
fallout 

shedding,  flaking,  metal 
chips,  filings,  air  fallout, 
personnel 

Assembly  & 

Integration 

air  fallout,  out- 
gassing,  personnel, 
cleaning,  solvents, 
soldering,  lubricants, 
bagging  material 

air  fallout,  personnel, 
soldering,  drilling,  bagging 
material,  shedding,  flaking 

Test 

air  fallout,  out- 
gassing,  personnel,  test 
facilities,  purges 

air  fallout,  personnel,  test 
facilities,  purges,  shedding, 
flaking,  redistribution 

Storage 

bagging  material,  out- 
gassing,  purges, 
containers 

bagging  material,  purges, 

containers,  shedding,  flaking 

Transport 

bagging  material,  out- 
gassing,  purges, 
containers 

bagging  material,  purges, 
containers,  vibration, 
shedding,  flaking 

Launch  Site 

bagging  material,  air 
fallout,  out-gassing, 
personnel,  purges 

bagging  material,  air 
fallout,  personnel,  shedding, 
flaking,  checkout  activities, 
other  payload  activities 
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Launch /As cent 

out-gassing,  venting, 
engines,  companion 
payloads  separation 
maneuvers 

vibration  and/or 
redistribution,  venting, 
shedding,  flaking 

On-Orbit 

out-gassing,  UV 
interactions,  atomic 
oxygen,  propulsion 
systems 

spacecraft  cloud, 
micrometeoroid  &  debris 
impingement,  material 
erosion,  redistribution, 
shedding,  flaking, 
operational  events 

3  CONTAMINATION  CONTROL  REQUIREMENTS 

In  general  the  assembly  and  integration  of  the  spacecraft 
will  take  place  in  a  Class  6  (ISO)  clean  room.  When 
testing  or  transportation  requires  the  spacecraft  to  leave 
the  clean  environment,  it  should  be  bagged.  Hardware  that 
is  not  being  actively  used  or  worked  on  should  be  covered 
even  when  in  the  clean  room  environment.  Hardware  should 
remain  surface  clean  in  visible  light  at  all  times. 

3.1  FABRICATION,  ASSEMBLY,  &  INTEGRATION 

Components  of  the  spacecraft  may  be  fabricated  in 
uncontrolled  environments.  This  does  not  preclude  the  need 
for  contamination  controls.  These  parts  should  still  be 
surface  clean  at  all  times  and  should  be  bagged  whenever 
possible.  Prior  to  entry  into  the  clean  environment,  each 
component  will  be  cleaned  thoroughly  with  a  compatible 
solvent  and  will  be  inspected. 

During  the  assembly  phase,  all  parts  will  be  stored  and 
assembled  in  the  clean  room.  All  test  and  support 
equipment  will  be  cleaned  prior  to  entry  to  the  clean  room 
and  will  be  kept  to  the  same  standard  of  cleanliness  as  the 
spacecraft  components  while  in  the  room.  During  operations 
that  require  soldering  or  the  application  of  lubricants, 
contaminants  should  be  removed  immediately  after  the 
operation  using  an  appropriate  solvent.  Areas  that  will 
become  inaccessible  due  to  assembly  should  be  thoroughly 
cleaned  and  inspected  prior  to  the  assembly. 

3.3  TESTING  &  TRANSPORTATION 

Generally,  contamination  requirements  during  testing  and 
transportation  are  the  same  as  in  previous  phases.  However, 
there  may  be  cases  where  coverings  must  be  removed  to 
perform  a  test.  In  this  case,  personnel  must  don  clean  room 
clothing  and  gloves  prior  to  handling  the  spacecraft. 

During  periods  of  inactivity,  the  spacecraft  will  be 
draped.  Out-gassing  tests  and  vacuum  bakeouts  must  be 
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followed  immediately  by  a  thorough  cleaning  of  the 
spacecraft's  surfaces.  After  cleaning  is  complete,  the 
spacecraft  will  be  visually  inspected.  It  will  then  be 
double  bagged  for  transportation  between  facilities.  The 
Spacecraft  will  be  transported  in  a  shipping  container  that 
has  been  be  pre-cleaned  to  a  visibly  clean  level. 
Temperature  and  humidity  will  not  be  monitored  in  the 
shipping  container. 
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